Am I right in thinking that, if AllowAutoQuit is True, then if the last window is closed there is no way to prevent the app from closing?

Also It looks like I need in fact to explicitly set it to False at startup, otherwise it will be True by default under Linux.

I need an orderly and controlled (by me) shutdown of my app if the user closes the one main window or chooses quit from the menu or clicks a quit button. So I have my own quitting property on the app, but to keep control I’m doing this in the main window’s CancelClose event:

if  (app.quitting=False)  then
  Quit ()
  Return True
end if

(quitting gets set in the app’s CancelClose event.)

Does Quit() actually return? Or does control enter Quit() and never return?

Taken from

AllowAutoQuit defaults to True on non-MDI Windows applications and True on Linux. It defaults to False on MDI Windows and macOS applications.

What does the debugger say, if you put a Break at Line 3?

It, um, breaks on line 3. Which I may say is a bit counter-intuitive and something that it would be useful to have documented. Execution continues step by step to the end of the event handler, after which the app quits.

Which is good since it allows me, when the user closes their window, to initiate quitting the app, but also preventing the close of the main window at that precise moment, important since the window contains stuff that needs to be saved.

1 Like

Why not offload the Windows Data to a Module or the Application Object and then close the Window and store the Data from within a Method at the Application Object?


  1. User Quits the App
  2. Data is moved to the Module/Application Object
  3. All/Main Window closes
  4. The Application Object stores/saves the Data
  5. The App finally quits

Well there’s certainly a variety of ways to organise it. In my case it’s also complicated by the fact that some of the data is inside an HTMLViewer and since I communicate back and forth with the HTMLViewer using a Websocket Server, which runs in a thread, I also need that server to gather and save the data first.

That would then go into Step 2 of my Workflow.
And if it may take a while until everything in Step 2 is done, maybe prevent further interaction between the User and the App? Maybe by disabling containers and the Close/Quit Buttons/Functions?
It should just not freeze at any time!

Sometimes you can see such App behaviour even in “Tripple A” Apps. :smiley:

But i would not rely on this behaviour. Better refactor the Code until Quit is the last command in the Method/Event.

It certainly is by design.
More intuitive and logical that way.