SetWindowsHookEx gives desired result only once?
-
In my dialog based MFC application, I initiate windows hook as follows
HHOOK TheHook; LRESULT CALLBACK ShellProc( int nCode, WPARAM wParam, LPARAM lParam ); BOOL CTmphookDlg::OnInitDialog() { .. .. HINSTANCE ppI = AfxGetInstanceHandle(); TheHook=SetWindowsHookEx(WH_SHELL, ShellProc, ppI,0); .. .. } LRESULT CALLBACK ShellProc( int nCode, WPARAM wParam, LPARAM lParam ) { if(nCode==HSHELL_WINDOWCREATED) { HWND hWnd = (HWND)(wParam); char szClassName[256]; GetClassName(hWnd, szClassName, sizeof(szClassName)); AfxMessageBox(szClassName); } return CallNextHookEx(TheHook, nCode, wParam, lParam); }
What I want is when any window (other applications) is created on the operating system.. it should flash a message telling its class name. But this code only shows its class name initially when the dialog is being created. I tried to open notepad or other windows of other applications, it didnt flash any message. Why is that so.? What to do to get this? Row -
In my dialog based MFC application, I initiate windows hook as follows
HHOOK TheHook; LRESULT CALLBACK ShellProc( int nCode, WPARAM wParam, LPARAM lParam ); BOOL CTmphookDlg::OnInitDialog() { .. .. HINSTANCE ppI = AfxGetInstanceHandle(); TheHook=SetWindowsHookEx(WH_SHELL, ShellProc, ppI,0); .. .. } LRESULT CALLBACK ShellProc( int nCode, WPARAM wParam, LPARAM lParam ) { if(nCode==HSHELL_WINDOWCREATED) { HWND hWnd = (HWND)(wParam); char szClassName[256]; GetClassName(hWnd, szClassName, sizeof(szClassName)); AfxMessageBox(szClassName); } return CallNextHookEx(TheHook, nCode, wParam, lParam); }
What I want is when any window (other applications) is created on the operating system.. it should flash a message telling its class name. But this code only shows its class name initially when the dialog is being created. I tried to open notepad or other windows of other applications, it didnt flash any message. Why is that so.? What to do to get this? RowYou're calling
SetWindowsHookEx
with thedwThreadId
set to zero and thehMod
set the the .EXE module handle. If you look at the documentation you'll see the following:dwThreadId
[in] Specifies the identifier of the thread with which the hook procedure is to be associated.
If this parameter is zero, the hook procedure is associated with all existing threads running
in the same desktop as the calling thread.All global hook functions must be in libraries.
In short you're you're using a global hook and global hook procudures must be in a DLL (that's how it gets into the address space of another process; the other processes loads it). You're hook procudure is in the MFC .EXE. Steve
-
You're calling
SetWindowsHookEx
with thedwThreadId
set to zero and thehMod
set the the .EXE module handle. If you look at the documentation you'll see the following:dwThreadId
[in] Specifies the identifier of the thread with which the hook procedure is to be associated.
If this parameter is zero, the hook procedure is associated with all existing threads running
in the same desktop as the calling thread.All global hook functions must be in libraries.
In short you're you're using a global hook and global hook procudures must be in a DLL (that's how it gets into the address space of another process; the other processes loads it). You're hook procudure is in the MFC .EXE. Steve
http://neworder.box.sk/newsread.php?newsid=10952[^] Please check this out . Regards, FarPointer Blog:http://farpointer.blogspot.com/
-
http://neworder.box.sk/newsread.php?newsid=10952[^] Please check this out . Regards, FarPointer Blog:http://farpointer.blogspot.com/
...which basically turns the EXE into a DLL :rolleyes:
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist -
http://neworder.box.sk/newsread.php?newsid=10952[^] Please check this out . Regards, FarPointer Blog:http://farpointer.blogspot.com/
WH_KEYBOARD_LL
andWH_MOUSE_LL
are special cases. The following is a quote from MSDN: "However, the WH_KEYBOARD_LL hook is not injected into another process. Instead, the context switches back to the process that installed the hook and it is called in its original context. Then the context switches back to the application that generated the event." This is why the example he gave works; it has nothing to do with his Microsoft conspiracy theories. My advice is to follow the rules and ignore that article. Steve -
WH_KEYBOARD_LL
andWH_MOUSE_LL
are special cases. The following is a quote from MSDN: "However, the WH_KEYBOARD_LL hook is not injected into another process. Instead, the context switches back to the process that installed the hook and it is called in its original context. Then the context switches back to the application that generated the event." This is why the example he gave works; it has nothing to do with his Microsoft conspiracy theories. My advice is to follow the rules and ignore that article. SteveYou are right steve. Regards, FarPointer Blog:http://farpointer.blogspot.com/