🚀 go-pugleaf

Have some thoughts about the WM_QUERYENDSESSION message.
when looking it up, it claims that each application is responsible to reply
true or false on this message.
If i want to intercept this message with the HookMainWindow() how do i
return a response to the OS?
What will be the OS action to a NO response? Will it try again with yet
another WM_QUERYENDSESSION until it finaly recevies a YES?

Im trying to but some time here, cuase I noticed when acting on the
WM_ENDSESSION message, the system goes down before my application has
finished its cleaning up operations.
Is there any other way aorund this that you know about?

/C

"Remy Lebeau (TeamB)" <gambit47.no.spam@no.spam.yahoo.com> wrote in message
news:3fb15956$1@newsgroups.borland.com...
>
> "Conny H�kansson" <conny@allimac.se> wrote in message
> news:3fb15541@newsgroups.borland.com...
>
> > Now that i know that this is a teadious task to accomplish I
> > want to know what messages to look for when using a
> > traditional application that is started when a user is login in
> > to the computer, and when he is login out.
>
> Under WinXP and 20003 only, you can use WTSRegisterSessionNotification()
to
> request the WM_WTSSESSION_CHANGE messages be sent to your app.  This is
not
> available on any of the other Windows OSs.  For those, there are no
messages
> for login, and for logout you can simply catch the WM_QUERYENDSESSION or
> WM_ENDSESSION message, which will tell you whether it is a logout or a
> shutdown.
>
> > Do I need to setup a system wide hook with the SetWindowsHookEx
> > function, which demands a DLL file to store the callback procedure
> > or is there a much simpler method to do this?
>
> No, you do not need a global hook at all.  For a normal app, just
intercept
> the desired messages in your form's WndProc() method, or alternatively use
> the TApplication::HookMainWindow() method to hook the hidden TApplication
> window (some messages may go there instead of to any of your forms).
>
> > I want some work to be processed when the user is login in,
> > aswell as when he logout's.
>
> In order to detect a login, your app must be executing as a service to
begin
> with so that it is running before the login occurs.  For a normal app,
that
> requires registering the app under the "RunServices" key in the Registry,
> and for the app to call RegisterServiceProcess() when it first starts up
and
> also when it is being terminated.  That will also allow the app to survive
a
> logout (which normally shuts down all non-service apps) by intercepting
and
> ignoring WM_ENDSESSION from killing the app.
>
>
> Gambit
>
>