SetWindowsHookEx global keyboard hook not catching all keypresses

Question

I\'m writing code that is part of an automation system. I wanted to add a keyboard hook to end the test prematurely, and I did this by using SetWindowHookEx.

My cod

Answer 1

Responding to your comment -

If you just need to test whether a key is down in order to exit your test, you could just poll on GetAsyncKeyState(), this will tell you if a particular key is down regardless of who currently has keyboard focus.

You user would have to hold a key or set of keys down long enough for your polling to notice, which means either they hold it down for a few seconds, or you have to poll more frequently than a second.

But that would be a lot less intrusive than a global keyboard hook.

Global hooks supposedly serialize parts of the kernel that normally would be async from each other, so they also harm system performance.

Answer 2

George Mamaladze's article Processing Global Mouse and Keyboard Hooks in C# which works if the application is "in the background" on CodeProject has been around since 2004, been through multiple revisions, and he's still supporting it and updating it : as I understand it, he started his project because he could not implement global hooks in .NET, that worked when the app was running in the background, but later discovered you could hook certain "lower level" events : formerly Q318804 : now MSDN article revised (?) that says you can hook WH_KEYBOARD_LL.

Perhaps, since George's code has been field-tested by so many C# programmers, over so many years, and extensively revised against bugs or problems : there's some possible value in his code for you ? In his article, in the Version 1 "FAQ" he shows code that will make the hook application specific, rather than global.

The MSDN article cited above mentions ... in the context of the allowed hooking of low level events, as you are doing :

"Low-level hook procedures are called on the thread that installed the hook. Low-level hooks do not require that the hook procedure be implemented in a DLL."

Hypothesis : could threading be related to what you are observing ?

I'm assuming you've already been through and considered all the details on : MSDN : LowLevelKeyboardProc Function