My app1 PostMessage WM_LBUTTONDOWN and WM_LBUTTONUP to app2 (third-party) which is in different process.
How to make sure those message been handled by app2 in app1, the logic in app1 depends on the result of those messages after PostMessage.
Here's the pseudo code for app1
PostMessage(app2Handle, WM_LBUTTON_DOWN, 0, lParam);
PostMessage(app2Handle, WM_LBUTTON_UP, 0, lParam);
// How to ensure above messages has been handled by app2 here?
PostMessage() works asynchronously. It simply puts the message into the target window's message queue and then exits immediately. There is no notification when the message is processed. If you need to know that, you could try using a message hook from SetWindowsHookEx() to monitor the activity of the target window's message queue and/or window procedure. Or, maybe you could use SetWinEventHook() to receive events like EVENT_OBJECT_INVOKED, EVENT_OBJECT_SELECTION..., etc if the mouse messages are meant to cause such click/selection actions in the window.
Related
It seems to me, WM_PAINT messages are send to a window while a thread with this window is waiting for a synchronous response of the COM server. The message appears after a while, or when other actions of user appear. I would like to change background color of the window in this case, but how can I find out, if WM_PAINT is sent as a result of blocking COM server, and not just send in other cases?
I tried to expect a flag while painting, maybe in PAINTSTRUCT, but there I found anything. I need another API call to check this condition.
I want to konw if there is a message pump in DestroyWindow,and if the message WM_DESTROY will be processed before DestroyWindow return.
This is my test code:
And the message posted before DestroyWindow still remains in the message queue when the WM_DESTROY is processed:
enter image description here
but when DestroyWindow return,the message posted before DestroyWindow will be removed:
enter image description here
There is no message pump in DestroyWindow. I submit that it is pretty obvious that any messages destined to a window that's being destroyed are dropped from the queue when the window is destroyed. Even in Windows 3.1, the alternative would be unthinkable because you can't know if another program's window is about to be destroyed. How much more so now when we have pre-emptive threading now.
I have an app that prompts the user for confirmation on exit, which is (indirectly) done by opening a confirmation dialog when the WM_CLOSE message is received. However the message is also sent by the task manager when the user uses end task on the process.
Because I prevent the window from closing with the confirmation dialog, task manager sees it as the process hanging and forcefully terminates it preventing the app from doing a graceful exit when it's possible.
Is there any way to determine if it's the user closing the window from the message (e.g. clicking the close button, or Alt+F4), and not the task manager? As the message's parameters are unused the only way I could think of is checking for mouse events or WM_SYSCOMMAND that were received some time before the WM_CLOSE is received, but I'm unsure if this would handle all cases.
I assume the task manager calls EndTask. Perhaps in the old days it only sent WM_CLOSE but it seems to send WM_SYSCOMMAND when I tested now so there are no clues in the messages you can use, it just looks like a normal Alt+F4.
If your app is asking about unsaved changes in a document, I would say, put up the dialog regardless and just accept the hard termination if that is what the user wants.
If you are just trying to prevent an accidental close, call GetForegroundWindow in WM_CLOSE. If you are not foreground, it was not an accidental close.
I'm trying to send text to 2 different textboxes in a 3rd party application.
And my code works. Although it doesn't work if my application executes in the background. Only if the program I send the text to is behind mine.
Does anyone know what causes this?
Use PostMessage not SendMessage - SendMessage waits for the message to be processed by the called winproc before it returns where PostMessage places the message on the application queue and returns immediately.
I have a window, and I am looking at the messages that are being sent to it using Spy++. Is it possible to determine which process sent my window a given message, if it indeed was sent from another process?
No, Win32 window messages do not contain information about where they were sent from (unless that information is specifically included as part of the message WPARAM and/or LPARAM components).