Hi.
I have a strange problem:
If my dialog is not in the foreground, i can't send it's procedure a message. if i try it with PostMessage or SendMessage, it does not arrive, and if i try it with CallWindowProc, an exception error occurs and when i hit the close button of the error message box of the kernel, another dialog pops up saying that an internal error in MS Internet Explorer occured and that i should close all applications and restart.

What? I don't understand that. Can someone help me on this one please? This is very very strange.

BTW: I try to send the window message from a dll (from a windows hook procedure (WH_KEYBOARD)). i'm filtering some key combinations in this procedure (something like hotkeys). if a valid key combination occured, it shall send a message to my dialog procedure telling my program that a "Hotkey" has been pressed. but as i said: i can't send messages when my program is not in the foreground!
Posted on 2001-09-14 12:13:47 by darester
Use the API "SendMessage":

invoke SendMessage, A, B, C, D

A == window handle to send the message to
B == The message to send (can be user defined or not)
C == the "wParam" 32 bit value relating to this message
D == the "lParam" 32 bit value relating to this message

I've never had a problem with this...

NaN
Posted on 2001-09-14 12:33:29 by NaN
well, as i already said, SendMessage does not work either. it looks like the window procedure is removed from memory everytime the dialog goes into the background.
Posted on 2001-09-14 13:28:46 by darester
maybe another thing:
when i try it with PostMessage or SendMessage, the return values of these two api functions show no errors, but the message just does not arrive at the dialog procedure.
Posted on 2001-09-14 13:30:53 by darester
How are you sending this message to the Dialog box??

Are you calling it from another dialog box... (modal/non modal).

Its possible the message is being queed an not processed because the calling thread is waiting for a return, somewhere else in your main dialog box. Depending how the windows exit, this message may never get processed.

PS: get the WinSpy utility on my webpage. It has a capture feature that will allow you to manually send messages to any window it captures.. I suggest manually sending this to see if its a code problem, or something deeper in the Window structure. You can also manually send Maximize/Minimize or Enable/Disable to this window, to test for other message types.

NaN
Posted on 2001-09-14 13:43:25 by NaN
thanks for your program NaN. i could successfully send a message with it. so i had to find out what's wrong with the code in my dll.
i found the following:
the window handle (which the dll receives when the hook is installed and saved globally in the dll) seems to become invalid (i don't know when/why).
i found that out when i tried to receive the window handle of the window again (with FindWindow) before i send the message to it. that worked.
how can that be?
i have a global variable in my dll in which the window handle is stored. from my main program i call InstallHook and pass it the main window handle. this handle is then stored in the global variable. what's wrong with this?
Posted on 2001-09-15 05:39:29 by darester
To be honest.. I dont know..

But i have in the past discovered that window handles get re-adjusted with out warning to some processes. As I use to program saving the handles (ie main window handles) and assuming i can continue using them, and not use the hWnd that i recieve in the message loop.. to my puzzlement, the same thing happenes..

All i can suggest is try to find a way of getting the handle on the fly, when your code needs it.?? Or perhaps someone else more skilled with DLL's (as im not often doing this) could add some help..

NaN
Posted on 2001-09-16 01:03:31 by NaN
darester: When you use a hook, the dll with the hook procedure is used in every process in the whole system (when it's a system wide hook of course). But windows requires that every process has it's own memory space and dlls. This also means that the DLL is unique to every process, so global data set in one process, is not the same as in another process.. This can cause your problem..
The solution is making the DLL code shared (for all processes), this can be done with a linker option (it's in one of Iczelion's tutors, I can't remember it right now)..

Thomas
Posted on 2001-09-16 03:18:42 by Thomas
thanks thomas. i'll try that out. i hope it'll work then :)
Posted on 2001-09-16 06:33:51 by darester