At power down ?

[LeP]

Additional remarks may be helpful for Windows users: in the QueryEndSession procedure it is recommended not to perform any cleanup operations.

That I do not understand. Do you have more info on that? From MS itself, not from some forum/?

https://learn.microsoft.com/en-us/windows/win32/shutdown/wm-queryendsession

When an application returns TRUE for this message, it receives the WM_ENDSESSION message, regardless of how the other applications respond to the WM_QUERYENDSESSION message. Each application should return TRUE or FALSE immediately upon receiving this message, and defer any cleanup operations until it receives the WM_ENDSESSION message.

[Thaddy]

No, you totally misunderstand that:
defer means it should call a clean-up, which by implication also means it can done in-place as I already thought.
There's no point leaving the procedure unless for any clean-up call.
E.g. calling free on a log is deferring, as are waitfor/free's on threads.
Or calling free on classes that is also defer in this context.

A better way to express it is like this: do not create something new inside the function, like a showmessage dialog, call the clean-up's and nothing more.

[LeP]

Uhmm .... I'm not convince about you explanation.
The sequence are clear and the words too.

ONE SHOULD WAIT WM_ENDSESSION message before start a cleanup, but sure not in the WM_QUERYENDSESSION elaboration.

In the WM_QUERYENDSESSION you must respond as quickly as you can and don't do cleanup.

I never wait WM_ENDSESSION, 'cause it take preciuos time for cleanup process (I have sometimes more then 30 seconds).

P.S.: if you don't respond in the WM_QUERYENDSESSION within 5 seconds, the OS will kill your application, I don't think you have enough time to make a cleanup inside.

[dbannon]

Five seconds sounds like it should be enough for most cleanups but I am quite sure there will be exceptions. Every (well, most) time I close Windows on my Laptop, it wants to do updates that always take a lot longer than 5 seconds, so there must be a means to extent that.   WM_ENDSESSION message might well be that means ?

I'm guessing that  WM_QUERYENDSESSION is captured by TApplication.QueryEndSession, looks like TApplication.OnEndSession captures WM_ENDSESSION to do  that extending ?

LeP, do you use TApplication.OnEndSession or do you handle the calls your self ?

Incidentally LeP, your input is mos certainly relevant, any docs we get together must be as cross platform as possible.

Davo

EDIT : I just tested the TApplication.QueryEndSession, successfully delaying shutdown for five minutes. You could really annoy your users ...

In a command line FPC app, using FPSignal(), its 90 seconds.

[Thaddy]

Although I have been using code like this for decades - in professional software with 100th of thousands of users - I have never run into a flaw.
So I think the addition is useful, but still think the way I interpret it is enough explanation.

(btw that code was written in Delphi, not Freepascal, although Freepascal compiles it nowadays)

I might add that a user interface is secondary to running a program. Delphi and Lazarus programmers often forget that:
It is the logic that performs, the GUI is ballast.

[LeP]

LeP, do you use TApplication.OnEndSession or do you handle the calls your self ?

This is the general code that I use since XP. Of course is on Windows. I do 99% Windows industrial applications. The GUI Interface is always present and it does only essential things like show something and interact with the user.

Code: Pascal  [Select][+][-]

1. type
2.   TFMain = class(TForm)
3.      ......
4.      protected
5.         procedure QEndSession(var Msg: TMessage); message WM_QUERYENDSESSION;
6.    end;
7.  
8. implementation
9.  
10.     function ShutdownBlockReasonCreate(hWnd: HWND; pwszReason: PWCHAR): BOOL; stdcall; external 'USER32.dll' name 'ShutdownBlockReasonCreate';
11.     function ShutdownBlockReasonDestroy(hWnd: HWND): BOOL; stdcall; external 'USER32.dll' name 'ShutdownBlockReasonDestroy';
12.      
13.     procedure TFMain.FormDestroy(Sender: TObject);
14.     begin
15.       //In this place is where all cleanup is done (generally speaking of course)
16.       ...............
17.       ...............
18.       ShutdownBlockReasonDestroy(handle);
19.     end;
20.      
21.     procedure TFMain.QEndSession(var Msg: TMessage);  //WM_QUERYENDSESSION
22.     begin
23.       ExitCode := 0;
24.       Msg.Result := 1;
25.       ShutdownBlockReasonCreate(Handle,  'Delayed'); //THIS TEXT IS SHOW ON THE WINDOWS SHUTDOWN SCREEN IF THE APPLICATION SLOW DOWN THE PROCESS.
26.       Close;
27.     end;
28.  

(btw that code was written in Delphi, not Freepascal, although Freepascal compiles it nowadays)

Yes, it was done in Delphi and it is used in Delphi.

I might add that a user interface is secondary to running a program. Delphi and Lazarus programmers often forget that:
It is the logic that performs, the GUI is ballast.

I'm in line with you, except that same applications (like mine)  needs GUI, so why not using some of their facilities ?
In my applications I use lot of external hardware and lot of TThreads, so I don't forget what the logic should do.

[jamie]

For Windows users

https://learn.microsoft.com/en-us/windows/win32/power/wm-powerbroadcast

However, you may need to add some additional work to your form or Application to capture it, like hook the message loop.

 For that, I do have a helper unit that will easily assist you in capturing that message.

 For others that are not on windows, I don't know. I suppose a file monitor in a thread watching a log file could help trigger an alert.

Jamie

[dbannon]

OK, here is my first cut at a Wiki page about the issues discussed in this thread.

https://wiki.freepascal.org/Shutdown_and_Powerdown

Much thanks to the contributors ! Please check out and flag any howlers you find.

Jamie, the things built into TApplication do seem to handle a Powerdown quite well,including Windows. What I have not addressed, and might well leave to people more familiar with Windows than me (and thats almost anyone) is when someone uses, eg, the Task Manager to kill an app.  In linux thats easy, just direct the 'signal' to a method that does what is needed. In Windows that is either WM_QUIT or WM_CLOSE but how to use them ?

LeP - I found no evidence of the 5 second limit you mention. But I did note that Windows gives you a dialog offering to kill a slow app after about (?) five seconds.

Davo

edit : typo, my keyboard is dying !

[LeP]

LeP - I found no evidence of the 5 second limit you mention.

I don't find the old reference about that (but I take a real applicaton locked and I press the power off button of a PC and this is the time that Windows wait for).
I remember it was related to shutdown procedure that Windows use at that now I know was changed over the time.

I have some win register keys where those times are exposed (there are other for services too), and they came from old defaults:

 - HKCU\Control Panel\Desktop\
   AutoEndtask
   WaittoKillAppTimeout
   HungAppTimeout

I tried to delete those and the effects on shutdown are the same. On the new systems these keys are not exposed, you must insert manually if you want to alter the times.
Every users can change the own times, depending on the applications.
By the way, these values were the default in the old times, and not enough for my applications. But with the API proposed Windows acts like I want.

I don't know if Windows, since those keys are not exposed anymore, acts in dinamic way for shutdown.

I will try with different machines and different configuration and loads to view how the shutdown acts.

But, since now what I have done is still working so I don't think to change it.

LeP - But I did note that Windows gives you a dialog offering to kill a slow app after about (?) five seconds.

Yes, the screen propose the name of all applications that slow down the process and also the string that you use in the API I show in the posts.

In Windows that is either WM_QUIT or WM_CLOSE but how to use them ?

WM_CLOSE message is sent to a FORM (or same controls) that should be closed. You can choose to really destroy or not the Form and all childs.
WM_QUIT is send to the Application, I don't know if you can intercept it normally or you must act in other way (I never catch WM_QUIT message).

There are more other messages the are sent to an application during the close process (like WM_DESTROY, WM_NCDESTROY, etc ..), but those no needs to catch too.