🚀 go-pugleaf

"Ok, let's start again...

I use the FormCloseQuery FormClose events and check/ask if files need to 
be saved.  The problem is that I also wanted/needed to detect when 
windows was shutting down because my app is designed to run 
unattended,like a service, and if the system was being shutdown with no 
one present, like by the UPS, I wanted it to just save and close.  To do 
this I trap the WM_QUERYENDSESSION message which is sent when Windows 
shuts down.  This is a technique that I have used for several years, and 
it worked fine in this application for more than 2 years.

About 6 months ago I did a major overhaul to the presentation layer.  i 
added a lot of graphics (some animated) along with user selectable 
skins.  I also added foreign language support, and a few new features.

In all of these changes, the close and end session routines did not 
change.

I released the update and started getting calls from users that their 
systems would not shutdown if the new version my application was 
running.  Previously they had no problems.

I tested and discovered that indeed, my application closed but Windows 
would not shutdown.  If I select shutdown again then Windows would 
shutdown.

I started looking for similar problems and solutions on the Internet and 
came across a couple of articles that talked about 3rd party component 
that is using 
AllocateHWnd and not calling DefaultWindowProc in the handler method can 
cause this problem.

Since I had just added a LOT of 3rd party components this looked like a 
good place to start.  Actually the first thing I did was double check my 
code to make sure all of my message handlers were done properly.

I can't debug the app while Windows is shutting down, because Windows 
always tries to kill the IDE first.  So I started by creating a basic 
test application with my close and end session code.  I ran it (outside 
the IDE) and restarted windows.  It saved the temp file, closed and 
Windows restarted.  This was a good starting place. 

I started adding components and restarting Windows so far everything 
works and this is very time consuming.

Looking for a better solution, I created a fake shutdown utility that 
would send a WM_QUERYENDSESSION message to my app in hopes that I could 
debug my app to see how it responded to the message.  Well it shuts down 
and returns true, which is what it is supposed to do according to 
everything I have read.  I actually expected to see my app to return 
false.

Now I have the situation where my real app returns true, but Windows 
shutdown is canceled.  My test app returns true but windows shutdown 
works properly.  If I set my test app to return false it also cancels 
windows shutdown.

Some of the suggestion here were that windows might be sending 
WM_QUERYENDSESSION to some window other the the main form.  This would 
certainly explain the situation where shutdown was canceled even though 
the main form returned true.  OK, I modified my fake shutdown utility to 
find the handle of TApplication and TFormMain, and they are the  same.

According to the docs I have Windows should only be sending to the main 
form of the app, so child forms should not be involved?  What other 
forms in my app could be involved?

Another suggestion was changing the way the whole close query end 
session thing works.  OK, I commented out the hook to the 
WM_QUERYENDSESSION routine so the message would not be trapped.  I made 
sure the files in my app were not modified so it would not ask to save.  
I tried to restart Windows.  My app closed quietly, but Windows did not 
restart.

I guess the fundamental question is how to isolate the cause.  Right now 
the most likely thing sounds like the hidden window theory.  Tracing 
messages sent to my app and debugging with the fake shutdown doesn't 
seem to be revealing anything.  I am thinking I need to find the 
mysterious hidden window.  Perhaps some component is creating a window.  
How can I enumerate all window handles on my system?

Sorry for "Gone With The Wind Volume Two"...