4

I am writing a program in MS VisualC++. I set a keyboard hook by hHook = SetWindowsHookEx(13,MyProc,GetModuleHandle(NULL),0);.

There is a bug in Win7, which I can reproduce, that disables my hook. When this bug happens, hHook is still TRUE, but UnhookWindowsHookEx(hHook) returns FALSE.

However, I want to restart hook only when it gets disabled, so I can't use UnhookWindowsHookEx.

How can I check if the hook still works? Something like GetHookStatus(hHook).

I found out that this Win7 bug is caused by some timeout or "garbage collection", but it is easier for me just to check hook status and restart if needed. I am not a pro, just coding as a hobby mostly for personal needs.

Thank you.

jww
  • 97,681
  • 90
  • 411
  • 885
Alexander
  • 49
  • 2
  • Are you sure it's a bug in _Windows_? For a start, `hHook` is `HHOOK`, not `BOOL`. Are you placing your hook in a separate library [as required](http://msdn.microsoft.com/en-us/library/ms644990.aspx)? – GSerg Mar 20 '11 at 10:52
  • The hook is set properly and works fine. The bug I am speaking of is the following: http://social.msdn.microsoft.com/Forums/en/windowsgeneraldevelopmentissues/thread/56093d14-c1bc-4d0a-a915-57fef0695191 . You are right about HHOOK! Maybe I should check one of it's parameters? But which one and how? – Alexander Mar 20 '11 at 11:14
  • 1
    This is not a very common complaint. You already know about the registry entry that configures the timeout. At least set it to a ridiculously high value and report back what difference it makes. – Hans Passant Mar 20 '11 at 13:37
  • Yes, I just implemented a registry fix and will report back of the results. I tried to compile a function to check hook state through undocumented user32.dll functions, but with no success. Still hope to find a working function to determine hook state. I think MS should've implemented such function when they changed hook's behaviour in Win7 from "resume hooking after a timeout" to "drop hook after a timeout". A function similar to what "UnhookWindowsHookEx" does now, but without unhooking, just to return hook status - TRUE/FALSE. – Alexander Mar 20 '11 at 16:46
  • 1
    Changing timeout helped. While this solution seems fine at home, it is for sure not acceptable in other cases. Changing low level system timeout requires access to registry and a reboot and may cause unexpected issues elsewhere. And on the other hand the issue can not really be solved by optimizing code - hook is dropped when system is busy or lages for some reason just once for more than 0.3 second. And no function to check hook's state (dropped or not) was introduced to compensate for this change of behaviour... – Alexander Mar 22 '11 at 20:02
  • 1
    If a timeout causes the "disconnect", you shold prevent the timeout. I found that adding Application.DoEvents(); to the callback thread's waiting loop is a must, to work properly. – CLS Apr 14 '15 at 11:44

0 Answers0