SetWindowsHookEx and WH_MOUSE
Trecius
I've a question regarding SetWindowsHookEx with WH_MOUSE.
I have created a DLL that sets a hook, which captures the WM_LBUTTONDOWN
only ONCE. When it determines that the user clicked the button, the hook
should be released. Here's my code...
HHOOK g_hHook;
HANDLE g_hEvent;
HINSTANCE g_hInstance;
POINT g_pt;
int WINAPI DllMain(HINSTANCE hInstance, DWORD fdwReason, LPVOID lpvReserved)
{
g_hInstance = hInstance;
return TRUE;
}
LRESULT CALLBACK MouseProc(int nCode, WPARAM wParam, LPARAM lParam)
{
if ((nCode == HC_ACTION) && (wParam == WM_LBUTTONDON))
{
g_pt = ((MOUSEHOOKSTRUCT *)lParam)->pt;
SetEvent(g_hEvent);
return 1;
}
else
{
return CallNextHookEx(g_hHook, nCode, wParam, lParam);
}
BOOL WINAPI UnhookWindow()
{
return UnhookWindowsHookEx(g_hHook);
}
POINT WINAPI HookWindow(HWND hWndToHook)
{
g_hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
g_hHook = SetWindowsHookEx(WH_MOUSE, (HOOKPROC)MouseProc, g_hInstance,
GetWindowThreadProcessId(hWndToHook, NULL));
WaitForSingleObject(g_hEvent, INFINITE);
MessageBox(NULL, "Point acquired!", "Acquired!", MB_OK);
UnhookWindow();
return g_pt;
}
Hopefully this is not too much code to discourage anyone looking at it. The
problem is the code never sets the event, so it never releases the hook. To
assist in debugging the problem, I put MessageBox() in the MouseProc just
before the SetEvent. Well, when I try my code with the message box, I click
the mouse button and my message box pops up, I acknowledge the message box,
but it pops up again! It pops up like 20 times before it finally stops
showing up. But the hook is still set, and if I click the window again, the
message box pops up another 20 times. It is like the event is never
signaled, so the hook is never released.
I thank you, all, for your feedback and comments. I hope to solve this
problem soon. Thank you once again.
Trecius
Igor Tandetnik
> I've a question regarding SetWindowsHookEx with WH_MOUSE.
>
> I have created a DLL that sets a hook, which captures the
> WM_LBUTTONDOWN only ONCE. When it determines that the user clicked
> the button, the hook should be released. Here's my code...
>
> HHOOK g_hHook;
> HANDLE g_hEvent;
> HINSTANCE g_hInstance;
> POINT g_pt;
>
> {
> g_hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
>
> g_hHook = SetWindowsHookEx(WH_MOUSE, (HOOKPROC)MouseProc,
> g_hInstance, GetWindowThreadProcessId(hWndToHook, NULL));
>
> WaitForSingleObject(g_hEvent, INFINITE);
> MessageBox(NULL, "Point acquired!", "Acquired!", MB_OK);
> UnhookWindow();
>
> return g_pt;
> }
You appear to be installing a hook into a different process. This causes
your DLL to be loaded into that process. Now, a DLL has a separate copy
of global variables in every process it is loaded into. If you debug
your hook proc, you will find that no global variables are actually set.
See KB article KB100634 "How to specify both shared data and non-shared
data in a DLL in Visual C++". But realize that:
a) g_hInstance should not be shared this way - in fact, it should not be
shared at all, it is only meaningful within a process.
b) g_hEvent cannot be shared this way - event handles are only valid
within a single process. You need to use a named event, or some other
IPC mechanism.
c) You have a race condition. Multiple mouse events may arrive into your
hook before the other process reacts to the signalled event and
uninstalls the hook.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Trecius
If you wouldn't mind, may I ask you more questions regarding DLLs.
...
"Igor Tandetnik" wrote:
> Trecius <Tre...@discussions.microsoft.com> wrote:
> > I've a question regarding SetWindowsHookEx with WH_MOUSE.
> >
> > I have created a DLL that sets a hook, which captures the
> > WM_LBUTTONDOWN only ONCE. When it determines that the user clicked
> > the button, the hook should be released. Here's my code...
> >
> > HHOOK g_hHook;
> > HANDLE g_hEvent;
> > HINSTANCE g_hInstance;
> > POINT g_pt;
> >
> > POINT WINAPI HookWindow(HWND hWndToHook)
> > {
> > g_hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
> >
> > g_hHook = SetWindowsHookEx(WH_MOUSE, (HOOKPROC)MouseProc,
> > g_hInstance, GetWindowThreadProcessId(hWndToHook, NULL));
> >
> > WaitForSingleObject(g_hEvent, INFINITE);
> > MessageBox(NULL, "Point acquired!", "Acquired!", MB_OK);
> > UnhookWindow();
> >
> > return g_pt;
> > }
>
> You appear to be installing a hook into a different process. This causes
> your DLL to be loaded into that process. Now, a DLL has a separate copy
> of global variables in every process it is loaded into. If you debug
> your hook proc, you will find that no global variables are actually set.
>
First, in DllMain(HINSTANCE hinstDLL ...), is the hInstance the instance of
the DLL? MSDN says so, but I'm just confirming it.
Second, as I see it, when I have a global variable, the variable is global
ONLY to the process with which it was called unless declared within a
#pragma. For example, let's use my g_hEvent variable. If I have two
programs running, and each program calls LoadLibrary(), then I will have TWO
SEPARATE g_hEvents. If delcared in a #pragma, INITIALIZED, and #pragma
comment(linker, ...) then ALL references of the DLL will share those
variables contained in the #pragma section. So if one reference of the DLL
changes a variable, then it will be reflected in all other references. Is
this correct?
> See KB article KB100634 "How to specify both shared data and non-shared
> data in a DLL in Visual C++". But realize that:
>
> a) g_hInstance should not be shared this way - in fact, it should not be
> shared at all, it is only meaningful within a process.
You're telling me not to include g_hInstance in the #pragma
data_seg("shared"), correct? Well, does it really matter? If my first
question holds true -- that hinstDLL is the instance of the DLL -- then all
programs that load the DLL will have the same hinstDLL, so in a sense, it
could be shared? Am I wrong here?
> b) g_hEvent cannot be shared this way - event handles are only valid
> within a single process. You need to use a named event, or some other
> IPC mechanism.
Again, are you telling me not to put g_hEvent in the #pragma data_seg?
Second, are you telling me to use CreateEvent(NULL, TRUE, FALSE, "MyEvent")
instead of CreateEvent(NULL, TRUE, FALSE, NULL)? In this case, the event
will be opened in the other process as it is now named.
> c) You have a race condition. Multiple mouse events may arrive into your
> hook before the other process reacts to the signalled event and
> uninstalls the hook.
>
> --
> With best wishes,
> Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925
>
>
>
Lastly, Igor, I would like to ask WHAT is being injected into the other
process when I call SetWindowsHookEx().
SetWindowsHookEx has the following arguments...
SetWindowsHookEx(idHook, lpfn, hMod, dwThreadId)
So when I call SetWindowsHookEx(...), am I injecting ONLY the lpfn, or am I
injecting the ENTIRE DLL?
Thank you once again, Igor.
Trecius
Igor Tandetnik
> First, in DllMain(HINSTANCE hinstDLL ...), is the hInstance the
> instance of the DLL? MSDN says so, but I'm just confirming it.
Yes. Note that HINSTANCE is only meaningful within the current process.
Every time a DLL is loaded into a new process, its DllMain is called
with its HINSTANCE for that process.
> Second, as I see it, when I have a global variable, the variable is
> global ONLY to the process with which it was called unless declared
> within a #pragma. For example, let's use my g_hEvent variable. If I
> have two programs running, and each program calls LoadLibrary(), then
> I will have TWO SEPARATE g_hEvents. If delcared in a #pragma,
> INITIALIZED, and #pragma comment(linker, ...) then ALL references of
> the DLL will share those variables contained in the #pragma section.
> So if one reference of the DLL changes a variable, then it will be
> reflected in all other references. Is this correct?
Correct. However, g_hEvent is a particularly bad example: you don't
_want_ it to be shared between multiple processes, as the handle is only
valid within the process that created or opened it (unless you jump
through hoops - see DuplicateHandle). You can use a named event to have
each process open its own handle to the single underlying event object
(see the last parameter to CreateEvent).
On the other hand, you definitely want to share g_hHook, as the hook
won't work correctly otherwise (you need HHOOK handle in
CallNextHookEx).
>> See KB article KB100634 "How to specify both shared data and
>> non-shared data in a DLL in Visual C++". But realize that:
>>
>> a) g_hInstance should not be shared this way - in fact, it should
>> not be shared at all, it is only meaningful within a process.
>
> You're telling me not to include g_hInstance in the #pragma
> data_seg("shared"), correct?
Correct.
> Well, does it really matter? If my
> first question holds true -- that hinstDLL is the instance of the DLL
> -- then all programs that load the DLL will have the same hinstDLL
Not necessarily. What makes you think so?
> so in a sense, it could be shared? Am I wrong here?
You are.
>> b) g_hEvent cannot be shared this way - event handles are only valid
>> within a single process. You need to use a named event, or some other
>> IPC mechanism.
>
> Again, are you telling me not to put g_hEvent in the #pragma data_seg?
Correct.
> Second, are you telling me to use CreateEvent(NULL, TRUE, FALSE,
> "MyEvent") instead of CreateEvent(NULL, TRUE, FALSE, NULL)?
Yes. You might want to choose a name that is more likely to be unique
though. A name based on a GUID is usually a good idea.
> In this
> case, the event will be opened in the other process as it is now
> named.
Yes. Of course, both processes should call CreateEvent with the same
name.
>> c) You have a race condition. Multiple mouse events may arrive into
>> your hook before the other process reacts to the signalled event and
>> uninstalls the hook.
>
> Lastly, Igor, I would like to ask WHAT is being injected into the
> other process when I call SetWindowsHookEx().
Your DLL, as if loaded with LoadLibrary.
> SetWindowsHookEx has the following arguments...
>
> SetWindowsHookEx(idHook, lpfn, hMod, dwThreadId)
>
> So when I call SetWindowsHookEx(...), am I injecting ONLY the lpfn,
> or am I injecting the ENTIRE DLL?
Entire DLL. There's no way for the OS to somehow pull a single function
out. Who knows what other functions or data it might depend on?
Trecius
reimplement my strategy. Thank you again; you were most helpful and answered
many of my questions regarding DLLs.
Trecius
Trecius
I have the following...
#pragma data_seg("shared")
HHOOK g_hHook = NULL;
#pragma data_seg()
...
LRESULT CALLBACK MouseProc(int nCode, WPARAM wParam, LPARAM lParam)
{
if ((nCode == HC_ACTION) && (wParam == WM_LBUTTONUP))
{
MessageBox(NULL, "Clicked!", "Clicked!", MB_OK);
return 1;
}
else
{
return CallNextHookEx(g_hHook, nCode, wParam, lParam);
}
}
For now I've taken out acquiring the point that the user clicks, etc. I
just want a message box to indicate that the DLL has noted a WM_LBUTTONUP.
When I run my program, and click on the destination window, again, I get a
lot of message box pop-ups, indicating "Clicked!" Why is this happening now?
Shouldn't my if-statement prevent multiple pop-ups? Thank you once again.
Trecius
Igor Tandetnik
> LRESULT CALLBACK MouseProc(int nCode, WPARAM wParam, LPARAM lParam)
> {
> if ((nCode == HC_ACTION) && (wParam == WM_LBUTTONUP))
> {
> MessageBox(NULL, "Clicked!", "Clicked!", MB_OK);
> return 1;
> }
> else
> {
> return CallNextHookEx(g_hHook, nCode, wParam, lParam);
> }
> }
>
> For now I've taken out acquiring the point that the user clicks, etc.
> I just want a message box to indicate that the DLL has noted a
> WM_LBUTTONUP. When I run my program, and click on the destination
> window, again, I get a lot of message box pop-ups, indicating
> "Clicked!" Why is this happening now? Shouldn't my if-statement
> prevent multiple pop-ups?
I would expect the following: you click on a window, and at mouse-up you
get a messge box. You click on its OK button trying to dismiss it, but
that action results in a mouse-up that produces another message box. If
you try to dismiss that one with the mouse, you get yet another, and so
on, until you get the message (no pun intended) and start closing them
by hitting Enter on the keyboard.
Is that what you see? Which part of your code do you feel should prevent
this scenario?