🚀 go-pugleaf

"A Nonymous" <anonymous@hotmail.com> wrote in message
news:Xns98ED90968E734anonymoushotmailcom@207.105.83.66...

> I trap/handle the WM_QUERYENDSESSION and WM_ENDSESSION
> messages to save my files and close.  I set the Msg.Result = 1
> (ok to shutdown) in each handler so Windows should continue
> to shutdown.  It use to work...

According to the documentation, the return value for WM_ENDSESSION is
0, not 1.

> I did some research and apparently any 3rd party component that
> is using AllocateHWnd and not calling DefaultWindowProc in the
> handler method can cause this problem.

I would expect that.  Any window message handler has to call
DefWindowProc() for unhandled messages.

> In that case the handler method is answering 0 to WM_QUERYENDSESSION
> which tells Windows to cancel the shutdown.

Correct.

> This is a BIG application and I use a lot of components. I created
> a new project and have been adding components one at a time to
> see what kills the shutdown.  With an almost 5 minute reboot cycle
> this is EXTREMELY time consuming. There must be a better way?

You would have to write a separate app that manually sends the
shutdown messages to a desired window, and then see how that app
responds to them.

> I also created a test application that sends the WM_QUERYENDSESSION
> and WM_ENDSESSION messages to my app in an attempt to "fake"
> the shutdown, but it seems to report that my app is responding
> properly.

There is no way to differentiate between a real shutdown and a faked
one.  If the app responds one way to the fake shutdown, then it has to
react the same way to the real shutdown as well.


Gambit