WM_(QUERY)ENDSESSION: Anyone have any insight on how to correctly catch this message and handle it?
WM_(QUERY)ENDSESSION: Anyone have any insight on how to correctly catch this message and handle it?
I have a hook into both of these messages. However, it's a little wonky;
- On Windows LOGOFF
- FormQuery() and FormClose() is called
- WM_QUERYENDSESSION and WM_ENDSESSION are sent
- FormDestroy() is called
.. but control doesn't come back to the *.DPR. I was expecting my code after the TApplication.Run() to run, like it does with a normal TForm.close() of the main-form. But it appears that there's a HALT in there somewhere and it doesn't seem to return from it.
I have a hook into both of these messages. However, it's a little wonky;
- On Windows LOGOFF
- FormQuery() and FormClose() is called
- WM_QUERYENDSESSION and WM_ENDSESSION are sent
- FormDestroy() is called
.. but control doesn't come back to the *.DPR. I was expecting my code after the TApplication.Run() to run, like it does with a normal TForm.close() of the main-form. But it appears that there's a HALT in there somewhere and it doesn't seem to return from it.
Yeah. I've spent the better part of a couple days on it. It appears that once this freight-train is rolling with the LOGOFF, the WM_ENDSESSION is handled by TApplication.WndProc() and a "Application.Terminate()" is issued. This will cause a cascade of calls to FormCloseQuery(), FormClose() and FormDestroy(), but the program control never returns to the *.DPR. It's a HALT. Kind of sucks.
ReplyDeleteAddExitProc() appears to be a solution, but it's been depreciated:
http://www.delphifaq.com/faq/delphi/vcl/f285.shtml
TeamB guy talking about it's path...
https://forums.embarcadero.com/message.jspa?messageID=442122
I've been gently moving the code that I need to run, up through this "cascade of calls", trying to find somewhere safe. Sadly, my clean-up code needs to perform a ShellExecuteEx() and this doesn't appear to be allowed once the WM_ENDSESSION has been handled. To complicate it, the ShellExecuteEx() is for a binary that uses RequireAdmin in the manifest. So a double whammy and probably going to be a problem with my architecture. Sad.
Well in FormCloseQuery you have a last chance to push the break on the train, you can set CanClose to False, process your stuff and then release the break. maybe that does the magic you need. I have tested against a windows shutdown and it stop it in its face!
ReplyDeleteThanks. That may well be it with FormQueryClose, as I believe it's at the top. I'll try harder.
ReplyDelete