2

I'm using a low-level keyboard hook (WH_KEYBOARD_LL) to disable certain input, such as Alt-Tab. I create the hook on a thread with a message pump, so I can properly handle the notifications.

The hook's callback function is able to process keyboard events whenever I'm not focused in the window that created the hook (i.e. my main window), but as soon as I activate that window, no events show up in the hook until I deactivate the window again and the input instead propagates to the window's WindowProc.

Does anybody have any clue what's going on here?

UPDATE: So, it turns out this behavior is caused by also registering for raw input in the same process. Apparently, using raw input causes my low-level keyboard hook to be disabled whenever my process’s window is focused. Does anybody know why and how to work around this?

dreijer
  • 654
  • 8
  • 22
  • Raw input intercepts input events before they are processed like normal. That includes hooking. – Hans Passant Oct 29 '12 at 22:16
  • As far as I know, raw input doesn't drop input; it merely acts like a sink. Things are working just fine whenever the window is *not* focused, but as soon as I focus it, the hook somehow gets disabled. – dreijer Oct 29 '12 at 23:33

1 Answers1

0

Windows doesn't call low-level keyboard hooks if the most recently registered hook (aka the first hook to be executed) comes from a process that registered itself for raw keyboard events.

So a workaround is to create a second low-level keyboard hook in another process afterwards. Yes, this will cause both low-level keyboard hooks to be executed even when the focus is on a window from the first process.

Bad for performance, and who knows what Windows will bodge next - so I'm not really endorsing it - but it works.

secondperson
  • 148
  • 1
  • 4