My House is Crumbling From Beneath Me

General
#1

I’ve usually got all kinds of shenanigans (like timers) going on when the user quits the app. To help, I have a flag in the App object called App.IsQuiting that I set during App.CancelClose. Anything complex checks this and aborts.

However, sometimes during quit when I check the flag, I find that the app object is nil, likely because it’s being destroyed as the app shuts down. This of course leads to worse shenanigans. It’s like having the floor fall out of the house as you’re trying to run out the door. Damn my slow feet!

Any thoughts on a better way to deal with this?

#2

Put the property in a module instead?

#3

What about setting a status flag to “QuitPending”, set a timer for a closeAllGracefully() routine and return True (cancel the quit). After you have take care of any necessary clean up routines in closeAllGracefully(), you set the flag to “ReadyToQuit” and Quit(). Now you can return False in the App.CancelClose() and the system will destroy everything. Something like that.

#4

I thought of that. I wonder if Modules get destroyed too as you quit.

If you cancel the close and then resume it, are you going to incur penalties. Like the OS thinking the app has refused to quit, etc?

#5

No OS involved. You just aborted the request to quit, and postponed it to your clean up routine to take care of. All your threads, timers, etc still running and you could take care of them there properly. You should return False after (App.CancelClose()), in the next quit(), launched by your clean up routine and then everything will be destroyed properly.

#6

I’d actually like to get the official word on this. Like Stephen, I’d have thought canceling the quitting process wouldn’t be a great idea. Pretty sure Matt Neuburg’s old book described the quitting process clearly, but it’s possibly inaccurate now.

#7

Module isn’t destroyed. I use this exact process.

#8

Ok, I would like to know if Xojo message event handling works in a different way of all the rest. I’ll be surprised if it does.

#9

There’s good details on the termination process of GUI apps here: http://documentation.xojo.com/index.php/Application.CancelClose

#10

Perfect. Exactly as I told. :wink:

#11

Yep, you’re right. So Application.Close is the final signal that the App is quitting (and this will be the stage that the OS is notified).

#12

Most of the time. It is possible for the OS to initiate the quit sequence. Then it might conclude that your app is hung if it takes too much time to clean itself up. But for user-initiated quit from within the app, you are correct, the OS doesn’t get involved.

#13

But that shouldn’t hurt anything (at least on the Mac). Apps that have unsaved documents, for instance, often will stop a shutdown sequence. The users gets an error message that “App x prevented the shutdown” or something to that effect. Then it’s up to the user to shut that particular app down in a safe manner.

Of course, newer apps are designed to auto-save all unsaved documents and reopen them on next launch, so that kind of shutdown abort happens less and less these days.

#14

Consider writing your apps using a Finite State machine paradigm.

#15