Wierd thread mousehook issue.

See more:

C++

I have mouse hook that is not global, but per thread in my own process.
I am a plugin into a larger app.

I look for: WM_LBUTTONDOWN, WM_LBUTTONUP and WM_LBUTTONDBLCLK.

In each case, I simply set a flag and "Get the heck out of dodge" by executing:

return CallNextHookEx(NULL, nCode, wParam, lParam);

When I DoubleClick the mouse on a window in the hooked app it I see the WM_LBUTTONDBLCLK come in and the window responds as expected.

If I Close that window via the [X] and double click another windows within the hooked app I don't see the WM_LBUTTONDBLCLK but the familiar WM_LBUTTONDOWN, WM_LBUTTONUP, WM_LBUTTONDOWN, WM_LBUTTONUP sequence which as a work around I time to "detect" the double click of this style.

I know that onlt windows with the WS_DBLCK will be sent WM_LBUTTONDBLCLK messages but they both do. Also it makes no difference which window is double clicked first, the second will always only receive WM_LBUTTONDOWN, WM_LBUTTONUP, WM_LBUTTONDOWN, WM_LBUTTONUP. And the window does not respond as expected. So I force it to.

This is ok, but I have found a bug in all this and before I band-aid the bug it would be better to discover why it seems like my hook is less than transparent to the host app or windows as removing my hook removes the problem.

I have also used: return CallNextHookEx(hMouseHook, nCode, wParam, lParam);

returning the global hMouseHook handle (which is valid) but doing so does not change the behavior.

Thanks a bunch, Happy Friday.
:Ron