Intercept all mouse event for a specified hwnd
-
of courese im sure. i place a messagebox at the if block, the messagebox will display there.
And does your process-id comparison become TRUE at the right times?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
-
But here he does exactly that, not call CallNextHookEx and return non-zero:
if(process\_id==target\_process\_id){//is that process to be hooked .... my process return 1;//or return 0 }Am i missing something?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
-
I want to hook a mouse events of a specified window. So, i install a WH_MOUSE hook callback procedure for that thread. If i didn't hook that message, the thread would show a pop menu when it received a right button message. After i hooked that thread, windows would call my callback procedure when such event occurred, but the original window's message handler would be called, too. But i want to hold such message to make the original window will not receive such message. I use global hooks but check the process id like:
LRESULT CALLBACK MouseHookProcedure(int nCode, WPARAM wParam, LPARAM lParam)
{
if(0 > nCode)
return CallNextHookEx(g_hPreviousMouseHook, nCode, wParam, lParam);//OutputDebugString(\_T("Mouse Hooked Event...\\n")); MOUSEHOOKSTRUCT \*pMouseHooksStruct = (MOUSEHOOKSTRUCT \*) lParam; DWORD process\_id; GetWindowThreadProcessId(pMouseHooksStruct->hwnd,&process\_id); if(process\_id==target\_process\_id){//is that process to be hooked .... my process return 1;//or return 0 } return CallNextHookEx(g\_hPreviousMouseHook, nCode, wParam, lParam);}
that, target_process_id is stored in the shared segment block, im sure its ok. How to fix such a problem? Regards.
Does GetWindowThreadProcessId return proper process id ? The only possibility is your if(process_id==target_process_id) is not satisfying. Check whether you've defined the shared section properly, and even look for values of target_process_id and process_id by debug printing them.
[Delegates] [Virtual Desktop] [Tray Me !]
-Malli...! :rose:**** -
And does your process-id comparison become TRUE at the right times?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
-
You are calling CallNextHookEx()[^] in both the case i.e. nCode > 0 or nCode < 0; You may return a nonzero value to prevent the system from passing the message to the target window procedure from your handler. Even have a look at this[^].
[Delegates] [Virtual Desktop] [Tray Me !]
-Malli...! :rose:**** -
yes, im sure. because i instore the target process' process id in a shared segment. And i also has placed a messagebox at that if block for testing.
Well, the documentation says that returning a non-zero value MIGHT prevent the system from letting the message go on his marry way. So i guess there's no assurance. How about altering the
MOUSEHOOKSTRUCT, for example, settinghwndto NULL before you return?> The problem with computers is that they do what you tell them to do and not what you want them to do. <
-
Does GetWindowThreadProcessId return proper process id ? The only possibility is your if(process_id==target_process_id) is not satisfying. Check whether you've defined the shared section properly, and even look for values of target_process_id and process_id by debug printing them.
[Delegates] [Virtual Desktop] [Tray Me !]
-Malli...! :rose:****yes, target_process_id do be defined in a shared segment:
#pragma data_seg (".SHARED")
HHOOK g_hPreviousMouseHook = 0;
HHOOK g_hPreviousWinProcHook = 0;
HINSTANCE g_hInstance = 0;
HWND g_hMinimizedWindowList[ARRAY_SIZE] = {0};
int g_iMinimizedWindowCount = 0;
DWORD target_process_id = 0;
#pragma data_seg()#pragma comment(linker, "/SECTION:.SHARED,RWS")
Malli_S, this code slice is copied from your tutor article http://www.codeproject.com/KB/system/TrayMe.aspx. Im trying your demo project today.
-
Well, the documentation says that returning a non-zero value MIGHT prevent the system from letting the message go on his marry way. So i guess there's no assurance. How about altering the
MOUSEHOOKSTRUCT, for example, settinghwndto NULL before you return?> The problem with computers is that they do what you tell them to do and not what you want them to do. <
No. My target test program is a simple mfc dialog with a tray icon, when you right-click the tray there will be a popup menu display. I want to hook the mouse messages so that the menu will not appear on the screen. No matter i return which value or change the hwnd member of MOUSEHOOKSTRUCT to NULL, the menu will always display, the difference is that, this menu will not receive messages any more.
-
No. My target test program is a simple mfc dialog with a tray icon, when you right-click the tray there will be a popup menu display. I want to hook the mouse messages so that the menu will not appear on the screen. No matter i return which value or change the hwnd member of MOUSEHOOKSTRUCT to NULL, the menu will always display, the difference is that, this menu will not receive messages any more.
Ah, you won't get mouseclick events from an icon clicked on the tray, that works differently. See here[^]. You can specify what message your application wants to receive if the icon gets clicked on the tray. You should probably look for that message instead of mouseclicks. You should have said that earlier. :)
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
-
Ah, you won't get mouseclick events from an icon clicked on the tray, that works differently. See here[^]. You can specify what message your application wants to receive if the icon gets clicked on the tray. You should probably look for that message instead of mouseclicks. You should have said that earlier. :)
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
-
Well, first you need to determine what that message is, as said, the application can TELL the shell what it wants to receive so bascily it can be anything. Try using spy++, maybe it helps, maybe it does not.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
-
I want to hook a mouse events of a specified window. So, i install a WH_MOUSE hook callback procedure for that thread. If i didn't hook that message, the thread would show a pop menu when it received a right button message. After i hooked that thread, windows would call my callback procedure when such event occurred, but the original window's message handler would be called, too. But i want to hold such message to make the original window will not receive such message. I use global hooks but check the process id like:
LRESULT CALLBACK MouseHookProcedure(int nCode, WPARAM wParam, LPARAM lParam)
{
if(0 > nCode)
return CallNextHookEx(g_hPreviousMouseHook, nCode, wParam, lParam);//OutputDebugString(\_T("Mouse Hooked Event...\\n")); MOUSEHOOKSTRUCT \*pMouseHooksStruct = (MOUSEHOOKSTRUCT \*) lParam; DWORD process\_id; GetWindowThreadProcessId(pMouseHooksStruct->hwnd,&process\_id); if(process\_id==target\_process\_id){//is that process to be hooked .... my process return 1;//or return 0 } return CallNextHookEx(g\_hPreviousMouseHook, nCode, wParam, lParam);}
that, target_process_id is stored in the shared segment block, im sure its ok. How to fix such a problem? Regards.
A mousehook seems like an overkill solution for getting all the mouse events for a window. Why not just get the messages in the window's windowproc (possibly by subclassing if it's not your window)? Or is the window in another app? Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Well, first you need to determine what that message is, as said, the application can TELL the shell what it wants to receive so bascily it can be anything. Try using spy++, maybe it helps, maybe it does not.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
ok. i used spy++ and found the tray icon always receives TB_GETBUTTONINFO message. and i googled found someone said i almost couldn't hook that message in its owner window's message loop, because TB_GETBUTTONINFO is internal messages in controls. right? If so, maybe i only can hook its owner window's main message callback procedure. any idea?
-
A mousehook seems like an overkill solution for getting all the mouse events for a window. Why not just get the messages in the window's windowproc (possibly by subclassing if it's not your window)? Or is the window in another app? Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
oh, Code-o-mat told me that the tray icon not use WM_RBUTTONUP message any more. yes, i used spy++ and found its message should be TB_GETBUTTONINFO message. Im trying to find a way to hook this message or another method to hook the real procedure of such message.
-
ok. i used spy++ and found the tray icon always receives TB_GETBUTTONINFO message. and i googled found someone said i almost couldn't hook that message in its owner window's message loop, because TB_GETBUTTONINFO is internal messages in controls. right? If so, maybe i only can hook its owner window's main message callback procedure. any idea?
I'm not sure but i think you misunderstood something, what i meant is the message that is received by the application if the tray icon is clicked. Usually this works something like: -the application uses Shell_NotifyIcon[^] to install an icon on the tray, specifying -for example- WM_USER or WM_APP or some other message it wants to receive when the icon is clicked on -the user right-clicks the icon on the tray, the application receives the message it specified when using Shell_NotifyIcon along with some other information telling it that the icon was right-clicked (you can look this up in the documentatin if you like), the message is targeted at the window that was also specified when Shell_NotifyIcon was used. -the application displays the popup menu at the mouse cursor's position and handles the user's menu selection So basicly, i gess what you want is to catch the message fed to Shell_NotifyIcon.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
-
yes, target_process_id do be defined in a shared segment:
#pragma data_seg (".SHARED")
HHOOK g_hPreviousMouseHook = 0;
HHOOK g_hPreviousWinProcHook = 0;
HINSTANCE g_hInstance = 0;
HWND g_hMinimizedWindowList[ARRAY_SIZE] = {0};
int g_iMinimizedWindowCount = 0;
DWORD target_process_id = 0;
#pragma data_seg()#pragma comment(linker, "/SECTION:.SHARED,RWS")
Malli_S, this code slice is copied from your tutor article http://www.codeproject.com/KB/system/TrayMe.aspx. Im trying your demo project today.