Propagating App Shutdown to Child Components


#1

I have a component in my app which needs to warn the user about unsaved data when the application shuts down. Putting my alert message in the destructor doesn't work because everything just keeps getting destroyed. I tried overriding 'userTriedToCloseWindow' but it doesn't seem to be being called.

I see the shutdown, systemRequestedQuit, and closeButtonPressed methods in the JUCEApplication and DocumentWindow classes, but these objects aren't really aware of the contents of the app and therefore can't access any of the methods I need.

I'm trying to make my code easily portable between a standalone app and a plugin so I don't want to do anything that's too specific to either one if I can help it. What's the cleanest way to call methods on a child component from the top level? Do I need to create a pointer to that child at the app level? I think what I really want is a 'pre destructor' function for the Component class. Maybe I missed something?

Less importantly, is there a way to make the AlertWindow::showOkCancelBox function use native window and button styles?

 

Thanks for your help


#2

Whatever you're building, if there's a list of things that you need to double-check before shutting down, that's something you need to implement yourself - it's not the kind of thing that a generic class would be much help with.

But do bear in mind that in a plugin, when your plugin is getting deleted, you can't just stop and have a conversation with the user! When you're deleted, you must immediately release everything, it's not an operation you can interrupt or abort.


#3

Thanks for getting back to me, Jules! I suppose this feature isn't really worth the trouble, not right now anyway. 


#4

You could automatically store the changes to a different place. Then the next time the program/plugin starts up, ask the user if he wants to keep those changes or revert to the last saved version.

 

On a side note, I like the idea of immedately saving changes as they happen. Then implement multiple undo to allow the user to get back to a previous state. Then you never have to explicitly save anything. But its a lot of work to implement. And if you want to get fancy and maintain undo information across runs of the program, it's even more work. I've never gotten around to ever implementing all this in an app, but I like the idea. (For undo, see the Command pattern in the Design Patterns book.)


#5

(FYI if you've not seen it: undo/redo is really easy to implement if you keep your state a ValueTree)