pepr
asked on
Log-off or shutdown -- WM_QUERYENDSESSION or WM_ENDSESSION?
How to use WM_QUERYENDSESSION and/or WM_ENDSESSION correctly in my case?
Hi experts,
I am adding reaction to the user log-off or the Windows OS shutdown to our application. I have read the MSDN documentation. I have decide to left the processing of WM_QUERYENDSESSION to DefWindowProc and to process only the WM_ENDSESSION.
The problem is that the application can be used both in interactive mode (with usual GUI) and in noninteractive mode (much simpler GUI that does not react to the user events). In noninteractive mode (launched by system scheduler, controlled by the application script) no message loop is created. Still, start and finalization of the application uses the same code.
When using the interactive mode, the finalization is done by the code placed after the message loop. When working in the non-interactive mode, the message loop is not entered at all.
Whe quitting the application in the interactive mode, finalization of the GUI is also done (remembering user settings...). It is done in WM_DESTROY handler of the main window. The OnDestroy() handler also does PostQuitMessage(0) at the end of its body. This causes leaving the message loop. Consequently, the application finalization place after the message loop (as mentioned above) is done.
My OnEndSession() handler looks this way (using ATL conventions):
LRESULT CWndDirector::OnEndSession
WPARAM wParam, LPARAM lParam,
BOOL& bHandled)
{
ATLASSERT(uMsg == WM_ENDSESSION);
ATLASSERT(wParam == TRUE);
ATLASSERT(m_pWnd != 0);
ATLASSERT(m_pWnd->IsWindow
m_pWnd->DestroyWindow(); // sending WM_DESTROY to the main application window
return 0; // should be returned when handled
}
It seems that the above DestroyWindow() causes the OnDestroy() handle but the application quits somehow more quickly than expected. The code after the message loop is not executed. Please, could you explain that?
Hi experts,
I am adding reaction to the user log-off or the Windows OS shutdown to our application. I have read the MSDN documentation. I have decide to left the processing of WM_QUERYENDSESSION to DefWindowProc and to process only the WM_ENDSESSION.
The problem is that the application can be used both in interactive mode (with usual GUI) and in noninteractive mode (much simpler GUI that does not react to the user events). In noninteractive mode (launched by system scheduler, controlled by the application script) no message loop is created. Still, start and finalization of the application uses the same code.
When using the interactive mode, the finalization is done by the code placed after the message loop. When working in the non-interactive mode, the message loop is not entered at all.
Whe quitting the application in the interactive mode, finalization of the GUI is also done (remembering user settings...). It is done in WM_DESTROY handler of the main window. The OnDestroy() handler also does PostQuitMessage(0) at the end of its body. This causes leaving the message loop. Consequently, the application finalization place after the message loop (as mentioned above) is done.
My OnEndSession() handler looks this way (using ATL conventions):
LRESULT CWndDirector::OnEndSession
WPARAM wParam, LPARAM lParam,
BOOL& bHandled)
{
ATLASSERT(uMsg == WM_ENDSESSION);
ATLASSERT(wParam == TRUE);
ATLASSERT(m_pWnd != 0);
ATLASSERT(m_pWnd->IsWindow
m_pWnd->DestroyWindow(); // sending WM_DESTROY to the main application window
return 0; // should be returned when handled
}
It seems that the above DestroyWindow() causes the OnDestroy() handle but the application quits somehow more quickly than expected. The code after the message loop is not executed. Please, could you explain that?
Last Comment
ASKER
You are right. The problem is that I want to execute the code after the message loop (this is by design). This probably means that I should react on WM_QUERYENDSESSION and process it as if it was a user's explicit action for closing the application. The doc says...
"If shutting down would corrupt the system or media that is being burned, the application can return FALSE. However, it is good practice to respect the user's actions."
This way I probably should react as "I do not want to shut down now" and then immediately start shutting down at the application level. This way, the good practice will be kept but not left to the OS.
Any other idea?
"If shutting down would corrupt the system or media that is being burned, the application can return FALSE. However, it is good practice to respect the user's actions."
This way I probably should react as "I do not want to shut down now" and then immediately start shutting down at the application level. This way, the good practice will be kept but not left to the OS.
Any other idea?
ASKER CERTIFIED SOLUTION
THIS SOLUTION IS ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Thanks!
ASKER
Well, I have to change the application structure (refactor). The reason is that the non-interactive mode of the application now just skips the message loop and uses the same finalization code after the message loop.\
Thanks for your help!
Petr
Thanks for your help!
Petr
Windows OS
This topic area includes legacy versions of Windows prior to Windows 2000: Windows 3/3.1, Windows 95 and Windows 98, plus any other Windows-related versions including Windows Mobile.
129K
Questions
--
Followers
--
Top Experts
Get a personalized solution from industry experts
TRUSTED BY
"If the wParam parameter is TRUE, the session can end any time after all applications have returned from processing this message. Therefore, an application should perform all tasks required for termination before returning from this message."
It appears that the application gets terminated by brute force right after your handler returns. You should ensure that the finalization code be executed directly in your handler, or maybe in another thread with the handler waiting infinitely on its handle.