Is there a easy way to intercept message such as WM_COMMAND ? (I want to know when the user access a menu in a other program.) (s)
Posted on 2001-04-10 06:41:00 by (scalp)
Salut (Scapl), (cool le pseudo), je pense que tu peux obtenir un message via l'api 'GetMessage', personnellement je l'ai jamais utilisé mais ça devrais marcher. Bonne journée
Posted on 2001-04-10 09:36:00 by Vom-bonjour:-()
Salut Vom, (je vais repondre en anglais, comme ca tout le monde peut suivre) The problem of GetMessage is that it can only intercept message of is own thread (i think...) and i want to intercept message for an other app. There is also PeekMessage, but it doesn't wait for a message... In fact, i'm afraid i am to learn hook... and get back to good old Icz tuts (again) ! (scalp)
Posted on 2001-04-10 09:57:00 by (scalp)
Hi, I had a thought on this, but I don't know if it would work or not. If you can't use GetMessage unless the message is sitting in the calling threads' message queue, I wonder if you could do it in reverse and get your second app to do a PostThreadMessage into that queue. Then when your app runs it could process that message as if it was its own. You don't say if your second app is your own creation or not. If not then you'd have to do a little bit of reversing by inserting an inline patch into the WM_COMMAND processing code to call the PostThreadMessage routine. Just looking at some of the API functions descriptions I was thinking the following **might** work (big might ;) In the "WM_" messages processing code of the app you want to monitor for user menu selection you'll need to create a patch (or if it's your own app just add the appropriate code). An inline patch of this type is fairly straightforward if you're familiar with using SoftIce. If not, I could probably help along those lines... You need to find a place to jump to your patch, which you can add in a new section or find some empty bytes to place it. If it's a particular Menu item you want to monitor this would likely be after Windows checks the MenuItemID. If you want to monitor *any* menu selection, then you'd need to jump to your patch just after it checks the Msg parameter for WM_COMMAND (111h). The idea behind the patch code itself would be to use FindWindow to get the Hwnd of the main window of *your* 1st app, then GetWindowThreadProcessId to get its PID, then finally PostThreadMessage to place a WM_COMMAND message (or any message you want) in its message queue, which you can process normally with GetMessage. You could choose a very unique Class name for your app so there's no mistake with the FindWindow call. Again, no idea if this would really work, but looking only at the descriptions of the 3 APIs I don't see any glaring "bonehead idea" flags :P ------------------------------------- The FindWindow function retrieves the handle to the top-level window whose class name and window name match the specified strings. This function does not search child windows. HWND FindWindow( LPCTSTR lpClassName, // pointer to class name LPCTSTR lpWindowName // pointer to window name --------------------------------------- The GetWindowThreadProcessId function retrieves the identifier of the thread that created the specified window and, optionally, the identifier of the process that created the window. DWORD GetWindowThreadProcessId( HWND hWnd, // handle of window LPDWORD lpdwProcessId // address of variable for process identifier ---------------------------------------- The PostThreadMessage function places (posts) a message in the message queue of the specified thread and then returns without waiting for the thread to process the message. BOOL PostThreadMessage( DWORD idThread, // thread identifier UINT Msg, // message to post WPARAM wParam, // first message parameter LPARAM lParam // second message parameter ----------------------------------------- 'Course there's probably a much easier way, I just can't think of one :) Regards, Kayaker
Posted on 2001-04-10 19:59:00 by Kayaker