When a user logs out, does the app receive a WM_DESTROY message or only WM_QUERYENDSESSION / WM_ENDSESSION? I save window placement on WM_DESTROY but doesn't seem to work on log out. Although you think at some point the Window has to be destroyed ?
System Shutdown Messages in MSDN,I'm sure you have read them, but you need to pay extra attention to Remarks in WM_ENDSESSION.
Applications that have unsaved data could save the data to a temporary location and restore it the next time the application starts. It is recommended that applications save their data and state frequently; for example, automatically save data between save operations initiated by the user to reduce the amount of data to be saved at shutdown.
The application need not call the DestroyWindow or PostQuitMessage
function when the session is ending.
Related
I have a Spring Boot application that is generally message driven but on special occasions, the incoming messages need to be stopped. However I cannot loose those messages, I need to buffer them and receive them in the correct order later.
There are myriads of questions asked and answered about stopping the Listener via the ListernerEndpointRegistry, such as here.
However when I stop the container the AnonymousQueue seems to disappear. I want the queue to stay on the exchange and buffer any messages, and receive them, when I restart. Is this possible or do I need to buffer them inside my application?
There are two options.
Don't use an anonymous (auto-delete) queue and use stop/start.
Don't stop the container; simply block the listener thread(s) when you want to suspend message delivery and wake them when you want to restart.
However I cannot lose those messages
If you cannot lose messages, you should NEVER use an auto-delete queue - you can lose messages at any time if you have a simple network glitch.
I'm building an application where I need to manage the drop-off screen, ie, the screen from where the user killed the application.
One way to solving this problem is to ask the JS client to send an event to the server. The event will be the last successfully executed screen. For eg:- if my application has 10 different screens, then the last screen which was successfully completed by the user, the client will send the server the screen_name.
Now when the client wants to know the screen from where the user dropped-off, it can make a GET call and fetch the same.
The cons I see with this solution is:-
1) Dependency on the client for sending an event. If while sending the event, the connection drops-off or the user killed the application(website), then the client has no way to send the event again. In this way, the user will come back again to the same screen which was successfully completed
2) Increased number of network calls.
Is there any way in which server can itself handle the drop-off state? I have RESTful APIs.
I have a program that shuts down another application when certain conditions are met. Now most of the time everything works out fine, but sometimes the app is writing to a file and leaves it in a half finished state and has no way of recovering it on restart. I thought that one could send soft close signals and escalate after certain timeouts to more aggressive close signals, going trough a list like this:
1. WM_CLOSE
2. WM_QUIT
3. WM_DESTROY
4. TerminateProcess().
Now I know that the program has no code to handle any signal it receives. Is there a possibility that certain FileHandler under Windows react gracefully on such soft signals or is there no use to sending those, if the app does not handle them explicitly?
This article says:
NOTE: A console application's response to WM_CLOSE depends on whether or not it has installed a control handler.
Does this mean if no control handler is installed sending 1-4 is just as good as sending 4 directly?
I've got no idea how window hooks work at the "system level". MSDN only touches what's going on very briefly:
A hook is a point in the system message-handling mechanism where an
application can install a subroutine to monitor the message traffic in
the system and process certain types of messages before they reach the
target window procedure.
My best guess is something like below:
Before each message is added to the message queue for a window, it'll first send the message to the global/local hooks, which may do something, depending on their hook procedures. After all global hooks and local hooks, the message is finally added to the window message queue.
However, MSDN says that for some of the types of hooks, it will monitor events, notifications etc.
An example is the WH_MOUSE_LL hook:
Installs a hook procedure that monitors low-level mouse
input events. For more information, see the LowLevelMouseProc hook
procedure.
When they say events, are we talking window messages, or do they mean something else?
Am I all wrong?
Yes, this is a mechanism for windows messages, you can process this data (messages) before they reach target window procedure (message loop).
If you want hook other process windows you can simply do this in DLL, and use DLL injection for inject your library to other process.
I am porting a library to Windows. In a function I need to block on the arrival of a WM_DEVICECHANGE message.
What options are available for doing this? As my code resides in a library I have little-to-no information on the current set-up (so if it is a Console application, a regular GUI application, if my code is being run in a spawned thread, and so on). Therefore what is the best way to wait for the arrival of a specific message?
Blocking and receiving Windows messages are mutually incompatible. You get messages by pumping a message loop. Since you cannot rely on the app pumping one, you'll need to do this yourself.
You will need to create a thread. Create a hidden window in that thread then run the standard message loop. The window procedure for that window can see the WM_DEVICECHANGE message. It can do what ever it needs to do, within the constraints of running inside a separate thread. Like setting an event to signal that a function should stop blocking.
The message is probably sent using BroadcastSystemMessage(). You could create a hidden top-level window and its window proc would probably get this message. I'm not sure; but that's what I'd try first.