|
What about removing WS_SYSMENU option
"I Think this Will Help"
<h5
alok gupta="" <br=""> visit me at http://www.thisisalok.tk
|
|
|
|
|
I am displaying a windows form from within a TAPI event handler to display some information about an incoming call. However the forms window is not selectable. When the cursor is moved into that window it just comes up with the busy shape. My guess would be that it does not have any event handler associated with it. Can anybody help with this problem and how to fix it?
|
|
|
|
|
Create a modeless dialog or other window elsewhere in program.
Have your TAPI handler post messages to this window concerning the TAPI status.
Some window messages are not processed from within a handler, they are only processed the next time through the window's message loop and your TAPI handler is probably not in a regular message loop, as you suspect.
|
|
|
|
|
Hi all,
I'm trynig to show the main window of another process and it's driving me crazy!!!!
I get the process handle using
Process* MyProcess[] = Process::GetProcessesByName("EXCEL");
I found the MainWindowHandle property of a process
MyWnd = MyProcess[0]->MainWindowHandle;
But... how to use it. I wasn't able to find any way to make .NET 2003 accept the __int32 (IntPrt) the propery return in any window managing function.
PLEASE HELP ME!!!!
Maurizio
|
|
|
|
|
MGrosso wrote:
MyWnd = MyProcess[0]->MainWindowHandle;
How about:
ShowWindow(MyWnd, SW_RESTORE); I don't use .Net so this is just a guess.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Hi all guru!
I tried to get the file associated icon location by using following code. but shinfo.szDisplayName is empty. Could you please point out the error?
<br />
SHFILEINFO shinfo;<br />
memset(&shinfo,0,sizeof(shinfo));<br />
CString loc; SHGetFileInfo("c:\\po.txt",FILE_ATTRIBUTE_NORMAL, &shinfo, sizeof(shinfo), SHGFI_ICON|SHGFI_SMALLICON|SHGFI_ICONLOCATION);<br />
loc.Format("%s",shinfo.szDisplayName);<br />
DeleteObject(shinfo.hIcon);<br />
Thanks
|
|
|
|
|
The icon index is in iIcon not szDisplayName. If you want to retrieve the display name, you need to add SHGFI_DISPLAYNAME to the flags mask.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Looks like you got everything handled.
Does the file actually exist?
Maybe you did not include this part...
You must initialize Component Object Model (COM) with CoInitialize or OleInitialize prior to calling SHGetFileInfo.
|
|
|
|
|
Hi All,
To create a new desktop we use CreateDesktop which returns the handle of the newly created desktop. Now when the work is done how do I destroy this desktop. CloseDesktop function just closes the handle but does not destory it. Any other API?
--------------
Vaibhav...
|
|
|
|
|
Why are you differentiating between "close" and "destroy?" When CloseDesktop() is called, the handle is closed. What's to destroy?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
CloseDesktop() is compitible with OpenDesktop(). If one has used OpenDesktop() which retrives the handle to an existing desktop then he/she has to use CloseDesktop() to close the handle but it does not destroy the desktop which was already existing before. In my case I am creating a new desktop using CreateDesktop(). I want to destory the desktop after my work is done. CloseDesktop() is not sufficient here.
--------------
Vaibhav...
|
|
|
|
|
In MSDN documentation of CreateDesktop, it is said that after you're done with the desktop handle, call CloseDesktop to close the handle.
You don't need to explicitly destroy the created desktop. Instead, when you close a desktop handle, if there are no more open handles to the desktop, the object is automatically destroyed. You can think it as a COM object. First you call CreateInstance, use the object, then call Release. If no more references to the COM object exist, the subsystem destroys the object and frees the memory. The same happens with desktop objects.
This is the way it is designed to work, because explicitly calling 'DestroyDesktop' on a desktop object (such as the main Windows desktop) which is still in use can have highly devastating results. That is the reason why the destuction of desktop objects is left to the subsystem, and you can only open and close handles to the desktop. Call it a security feature, or just the prevention of malicious use, if you like.
-Antti Keskinen
----------------------------------------------
"If we wrote a report stating we saw a jet fighter with a howitzer, who's going to believe us ?"
-- R.A.F. pilot quote on seeing a Me 262 armed with a 50mm Mauser cannon.
|
|
|
|
|
hello everyone...
i have this thing that drives me crazy..this thing is:
i have a dll that exports a function "Func"...and i'm making (in another project) a namespace that has this function...the problem is that i can't use this function in a namespace but i can use it easily if it's not in a namespace...the error reported is LNK2019...
what should i do..
|
|
|
|
|
saeedmalas wrote:
...the error reported is LNK2019...
Is this a .Net-related error?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Do you mean the function is exported outside any namespace and then tried to import inside a namespace? If so, I guess you're out of luck, namespace location has to coincide. Think of the namespace(s) a function is located into as part of its "name". A workaround could be the following:
declspec(dllimport) void foo();
namespace A
{
using foo;
}
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Want a Boost forum in Code Project? Vote here[^]!
|
|
|
|
|
i'm using the .net ide but i'm not using any new .net managedcode just regular cpp code...
the functions in the dll are exported using a .def file...
so they have their original names...how can i make a namespace in another project to encapsulate these functions...
this is the same thing that microsoft made with GDI+...
|
|
|
|
|
i want to do the same thing as Gdi+ dll...
|
|
|
|
|
Can any one of you tell me how to swap two buttons which are placed on and Dialog box which is MDI based application and the buttons are owner draw buttons
kindly suggest me some idea
Request to all to continue this
|
|
|
|
|
Are you talking about the MoveWindow() function?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
By "swap" do you mean showing/hiding the buttons? If so, see the doc on ShowWindow().
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Hello
What i mean is i want ot select the button on the dialog box and move it along with my mouse and place it on the other button which is also on the current dialog box only and when i place likethat the two buttons should get swaped in there location
first of all i am notget the handler of the button on the dialog box
i am using GetActiveWindow();
GetWindowRect();
GetClientREct();
non of them are giving me the handle to my button or the coordinates ofthe button
plz suggest me some idea
Request to all to continue this
|
|
|
|
|
Hi all,
I am developing a driver for communication with some PLC's. First, I thought to create a win32 dll, but because I need to be able to send and receive messages, I start using MFC.
One of the requirements of the driver was that it could be used in VC++, Visual Basic, VB.NET, C# (so a lot of different languages).
Well, because I have developed a class that needs to be called in the dll (so you can use driver->Connect() and so on), I needed to export a class. But, in this case, other languages such as visual basic wouldn't understand the dll.
Then, someone gave me the advice to use COM objects. Well, it seems very hard to learn using COM, and some people say it will not be used anymore soon.
Now is my question, what is the best way to develop this driver???
Thanks!
Geert
[url]http://geert.yoki.org[/url]
|
|
|
|
|
Hi !
I'm somewhat unsure what you're trying to do. I take it that PLC stands for Programmable Logic Controller, yes ? In this case, how do these controllers connect to your PC ? Do you have any hardware-level drivers which allow sending and receiving data from the controller ? Or is it your task to develop a Windows hardware driver to communicate with the controllers ?
If you're developing a hardware driver, DO NOT USE MFC. That's something you just DO NOT do. Drivers are written mainly in C, and do not use MFC. If you've never written a hardware driver, then you're in for a mess. First write the driver itself, then consider options on how to allow client access to the driver. Do not incorporate direct client access to the driver itself (that means, use a DLL to interface a client application to the driver), because this hampers the reliability of the driver. Unreliable drivers will crash the OS.
If you already have a device driver provided by the PLC manufacturer, that allows you to send and receive data from the controller, and you're building the DLL that allows flexible access to the driver, then you can use MFC if you need to, but it's again not recommended. MFC is mainly for user interface applications, or solid Windows applications.
In this case, the best option is to create a COM component which, when opened up, opens a handle to the device driver, and then offers an interface through which data can be written and read. Writing a COM component is quite easy when you use the wizards. They generate most of the background code and your job is to implement the actual business logic.
To get you started on COM development, consult your local library for possible books. Rest assured, COM will not go anywhere, it will remain around for a long time still. Learning it is useful, because a lot of Windows subsystems, such as WMI or DirectX, are implemented as COM objects.
If you need more information, post more details on the project, such as what the PLC actually is, if you have a hardware driver from the manufacturer and what the precise task you're trying to accomplish is.
-Antti Keskinen
----------------------------------------------
"If we wrote a report stating we saw a jet fighter with a howitzer, who's going to believe us ?"
-- R.A.F. pilot quote on seeing a Me 262 armed with a 50mm Mauser cannon.
|
|
|
|
|
Thanks a lot for your answer!
Well, you are right, PLC stands for Programmable Logic Controller. The communication is done via TCP/IP, so I can use winsock for communication.
In my driver I have developed several classes. One to communicate with the PLC using winsock, one to communicate with the user, and a few extra classes.
I don't think (at least I hope) that I don't have to write real hardware drivers, because that wouldn't be nice...
You say I shouldn't use MFC. Well, I didn't plan to use it, but I needed a window handle to communicate with winsock (to receive messages). To do this, I needed the class CWnd, which belongs to MFC. Are there other possibilities to be able to receive messages???
Geert
[url]http://geert.yoki.org[/]
|
|
|
|
|
Hello !
Ah, this explains a lot. You're writing the user-mode component that allows communication with the device. The hardware drivers are already there, so you don't need to write them.
To help you get started, decide how the user should be able to use the PLCs. What services do they require ? Must they be able to write a program for the PLC and upload it ? Should they be able to read the program from the device and need a way of illustrating (such as a schematic) which shows what the device is currently programmed to accomplish ? Drawing a diagram (UML or otherwise) helps you design a solid structure on which to build.
After these decisions, the rest is quite trivial. You should follow standard COM strategy, in which you do not provide a direct access (a handle) to the device, but an interface, through which interaction is done. This will limit the user's possibilities to those which you have previously outlined, thus eliminating the user from accidentally or purposefully misusing your device. Writing an interface is as simple as writing a pure virtual base class, deriving from this class, and implementing the methods in the derived class. Then, you create a DLL which generates the class objects for each PLC device connected, and offers a routine through which a pointer to the interface class is returned to the caller.
Using interface classes is very useful. You only need to provide the base class header file for the user, alongside with the exported DLL routines, a possible .lib file, and the actual DLL. No source code is required, because the runtime will worry about redirecting the virtual function calls to the object in which these functions are implemented. Namely, the one which the DLL creates and upkeeps.
The internal implementation of the DLL depends on how you wish to present it. Winsock makes use of window objects to handle messaging (a Windows Message is sent whenever data is sent/received or the device is connected). You don't need MFC to create window objects. Just register a WNDCLASS structure and call CreateWindow, like in a normal Win32 program.
Unless you already knew, MFC is a collection of classes which wrap standard Windows routines. For example, CWnd is class which encapsulates the creation and displaying of a Windows window object. But you don't have to rely on MFC to create the window objects. You can create them manually as well.
There are many, many websites which show you how to create Win32 window objects. MSDN is full of examples: just whip out any Hello World -example for Windows, and you'll see how it's done. The key strategy is that although your DLL creates a window object, the object itself is made to be 0 pixels in heigth and width. Thus, it is invisible to the end user, although it is still there. This is a common strategy, and it's called 'hidden message windows'.
If you feel you're in a loss with standard Windows programming, I heartly recommend investing on the Charles Peltzoid's book 'Programming Windows'. It is The Bible of every Windows programmer and a must have if you intend to write Windows programs without MFC, or wish to learn more on how Windows OS works.
-Antti Keskinen
----------------------------------------------
"If we wrote a report stating we saw a jet fighter with a howitzer, who's going to believe us ?"
-- R.A.F. pilot quote on seeing a Me 262 armed with a 50mm Mauser cannon.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
