Window Not Receiving WM_KEYDOWN/WM_KEYUP Events

1
votes

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.
2
c++windowswinapiwindows-messages
It probably uses raw input. – Hans Passant
Does the window even get input focus? – andlabs
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
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
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

2 Answers

0
votes

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.

-1
votes

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.