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.
Related
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.
When you use the Maiar Exchange with the Chrome Extension and send a transaction, you can see that the extension window automatically closes after sending the transaction.
When I implement the same behavior, the Extension window stays open and the sendTransaction() Promise only resolves after the call is done. If I close the window by myself by clicking somewhere else on the website, I get the following error in the console:
Uncaught (in promise) Extension window was closed without response.
With that error, my promise success resolving code is not executed anymore which basically forces the user to wait about 30 seconds until the transaction is done.
This happens when using the sendTransaction() method of the ExtensionProvider from erdjs.
Does anyone have an explanation how e.g. the Maiar Exchange solves this?
The way the Maiar Exchange handles this is slightly different from your approach.
Sending the transaction directly with the ExtensionProvider requires that the extension window stays open until it is finished to return you the result.
However if you only use the ExtensionProvider to sign the transaction using the signTransaction method and send it yourself via the ProxyProvider you won't run into this limitation. The signing is basically instant and quickly closes the extension window. It also allows you to retry sending, without user interaction, if you run into any timeouts or similar.
I am trying to send data from one app to another using WM_COPYDATA. Both apps are console and have no window. I can send user messages just fine. When I try to send WM_COPYDATA, and setup the data structure or not, I get error 1159, which basically says I have to send using a synchronous message call... yet there is no SendThreadMessage.
It seems this is a oversight in the api or docs? There seems to be no way to use WM_COPYDATA using only threads without windows?
WM_COPYDATA can only be sent and cannot be posted. Because the payload is marshaled between processes, temporary data structures are created to support that marshaling. They need to be destroyed when the message processing is complete. That implies that the message must be delivered synchronously.
All of this means that you cannot use PostThreadMessage. Instead you will need to create a window to act as the recipient of such messages. Note that this window can be a message-only window and does not need to be visible.
Is there a way in windows phone to track sent message event? i mean to say that whenever a message is sent then a function of my application execute
all i want is to execute a function whenever sent message button of windows phone is clicked?
If you open the message launcher (I don't remember the exact name), it'll open this screen and you have the event (something like application deactivated) and once the user sends the message, the screen should close and come back to your app (again another event is available at that point, activated).
So you'll have to play with the events to do something you like, IIRC there is no call back when the message button is clicked.
Here's a link with the lifecycle of apps
There is no API that notifies you if a message was sent (at least no open API). A similar question was asked here.