1

I am hooking onto another processes main window via SetWindowHookExA (injected from a DLL) and attaching to the WH_KEYBOARD event. However, my callback is never called but the hooking succeeds and I do get the original value in return.

Upon investigating with Spy++, it seems the window never receives any WM_KEYUP / WM_KEYDOWN etc. messages at all. Digging further with a debugger I can confirm the window messages are being handled by PeekMessage / TranslateMessage / DispatchMessage so the events should occur as normal according to MSDN based on PeekMessage. Yet they never seem to happen.

Is there something that allows a created window to block these messages from ever happening to their window? (I've tried hooking onto the WNDPROC as well via SetWindowLongPtr, and still no go, my callback receives all messages fine, but the WM_KEY* messages never happen.)

The application does use DirectInput, however in other previous projects that have used DirectInput, the keyboard messages still happen as normal.

Just a quick recap of what I've tried and such:

  • SetWindowsHookExA with WH_KEYBOARD; callback never called.
  • SetWindowLongPtr with GWL_WNDPROC; call is hit, never sees keyboard messages.
  • Confirmed window does use PeekMessage to process its messages, so keyboard messages should happen fine.
atom0s
  • 485
  • 6
  • 22
  • It probably uses raw input. – Hans Passant Jan 24 '15 at 19:32
  • Does the window even get input focus? – andlabs Jan 24 '15 at 22:35
  • Yes focus happens. The mouse fully works fine. Hooking the mouse with WH_MOUSE works fine and messages are processed as expected. The window can be brought into focus etc. no problem. So I can't see anywhere that the window is not being focused properly for input. – atom0s Jan 24 '15 at 23:59
  • Someone else has installed a global keyboard hook and fails to call `CallNextHookEx`. In this scenario, keyboard input can still reach the target window, but all other hooks in the chain won't get a chance to see it. – IInspectable Jan 25 '15 at 18:17
  • No other hooks are installed by anything else. I have hooks in place to prevent any other hook being applied after mine, and none even attempt to be created. – atom0s Jan 26 '15 at 02:44

2 Answers2

0

I landed up just hooking onto DirectInput and creating the keyboard handling stuff I needed through that. It was not something I wanted to do but in the end the result works as needed.

atom0s
  • 485
  • 6
  • 22
-1

MSDN says that you can indeed filter messages before they even reach your WNDPROC. Take a look at this page. You'll probably have to hook into a higher location in the stack, or just rethink your approach.

Kaslai
  • 2,445
  • 17
  • 17
  • Looking into how they call things, it does not appear that there is any filtering happening. They call PeekMessage with nearly all null arguments except to remove the message when it is called. So from the look of it they are not filtering out the resulting message(s) at all. – atom0s Jan 24 '15 at 19:35