Is there any way to verify a HHOOK?
-
In a recent project I used WH_JOURNALRECORD to moniter certain events occur in a particular application window, but as MSDN said, as soon as the user press "CTRL+ESC" or "CTRL+ALT+DEL", all installed WH_JOURNALRECORD hooks will be wiped out by the OS... When this happens, my application does not know, so it would still wait for messages(which will never come anymore) from the target window. My questions is that, is there any way to verify whether a HHOOK handle is still on a "valid" state, so I can reinstall the hook if needed? Thanks
-
In a recent project I used WH_JOURNALRECORD to moniter certain events occur in a particular application window, but as MSDN said, as soon as the user press "CTRL+ESC" or "CTRL+ALT+DEL", all installed WH_JOURNALRECORD hooks will be wiped out by the OS... When this happens, my application does not know, so it would still wait for messages(which will never come anymore) from the target window. My questions is that, is there any way to verify whether a HHOOK handle is still on a "valid" state, so I can reinstall the hook if needed? Thanks
=[ Abin ]= wrote:
When this happens, my application does not know, so it would still wait for messages(which will never come anymore) from the target window.
You actually can detect eviction of the hook by the OS. From this[^] article, "Windows sends a WH_CANCELJOURNAL Windows message when it evicts the hook. The trouble is, the message doesn't have a Windows handle, i.e., it is not directed at any window, so how do we get to know about it? By now, the answer should be obvious, use another systemwide hook, this time a Windows Message Hook (idHook = WH_GETMESSAGE). This hook will get called whenever any Windows application calls GetMessage or PeekMessage, so we can catch WH_CANCELJOURNAL there and inform our UI that recording/playback has been interrupted." If you want source code, you can take a look at the linked article. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
=[ Abin ]= wrote:
When this happens, my application does not know, so it would still wait for messages(which will never come anymore) from the target window.
You actually can detect eviction of the hook by the OS. From this[^] article, "Windows sends a WH_CANCELJOURNAL Windows message when it evicts the hook. The trouble is, the message doesn't have a Windows handle, i.e., it is not directed at any window, so how do we get to know about it? By now, the answer should be obvious, use another systemwide hook, this time a Windows Message Hook (idHook = WH_GETMESSAGE). This hook will get called whenever any Windows application calls GetMessage or PeekMessage, so we can catch WH_CANCELJOURNAL there and inform our UI that recording/playback has been interrupted." If you want source code, you can take a look at the linked article. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
=[ Abin ]= wrote:
When this happens, my application does not know, so it would still wait for messages(which will never come anymore) from the target window.
You actually can detect eviction of the hook by the OS. From this[^] article, "Windows sends a WH_CANCELJOURNAL Windows message when it evicts the hook. The trouble is, the message doesn't have a Windows handle, i.e., it is not directed at any window, so how do we get to know about it? By now, the answer should be obvious, use another systemwide hook, this time a Windows Message Hook (idHook = WH_GETMESSAGE). This hook will get called whenever any Windows application calls GetMessage or PeekMessage, so we can catch WH_CANCELJOURNAL there and inform our UI that recording/playback has been interrupted." If you want source code, you can take a look at the linked article. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
Well, for some odd reasons the
GetMsgProcfunction in my application was never called, even thoughSetWindowsHookEx(WH_GETMESSAGE,GetMsgProc,m_hInstance,0)had succeeded... Weird isn't it? It was an MFC dialog based application.One possibility is that some other app installed a GETMESSAGE hook and is not forwarding it to subsequent hooks in the chain. I also realized that my code (the one in the article) is potentially buggy. According to MSDN, global hooks, except for journal hooks, need to reside in a DLL. But my GetMsgProc doesn't. Could you try making it a thread specific hook instead, by providing the current thread id as the last parameter? Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
One possibility is that some other app installed a GETMESSAGE hook and is not forwarding it to subsequent hooks in the chain. I also realized that my code (the one in the article) is potentially buggy. According to MSDN, global hooks, except for journal hooks, need to reside in a DLL. But my GetMsgProc doesn't. Could you try making it a thread specific hook instead, by providing the current thread id as the last parameter? Regards Senthil _____________________________ My Blog | My Articles | WinMacro
If he makes it a thread-specific hook, then it might still not receive the expected message notifying the journal hook was cancelled. Better to make it global and place it in a DLL. No shirt, no shoes, no brains, no service.
-
If he makes it a thread-specific hook, then it might still not receive the expected message notifying the journal hook was cancelled. Better to make it global and place it in a DLL. No shirt, no shoes, no brains, no service.
The MSDN[^] documentation does say that Windows sends the message to the application that set the journal hook, so I guess a thread hook should be okay. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
The MSDN[^] documentation does say that Windows sends the message to the application that set the journal hook, so I guess a thread hook should be okay. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
The hook's thread identifier should be the same thread identifier as the thread containing the window that will receive the message. If you set the hook from some secondary thread, it might not receive the message. No shirt, no shoes, no brains, no service.