if you use a ApplicationCommandManager (as member) in a class has which uses “DeletedAtShutdown” and create this object before the Desktop (because no GUI interaction is done before), the Desktop will be recreated after its deleted by the DeletedAtShutdown and you will get memory-leaks, because ApplicationCommandManagers destructor uses Desktop::getInstance() which creates a new Desktop again.
This can also be a problem for all other classes which are using Desktop::getInstance() in the destructor and DeletedAtShutdown at the same time, so i think its better:
create the Desktop in the juce gui startup-procedure, so its deleted at last in DeletedAtShutdown
or
don’t use the DeletedAtShutdown mechanism for the desktop, delete it separately at last in the gui shut-down procedure.
yeah… hard-wiring the order of creation of various system objects would be a move in the wrong direction, I’ve been trying to get rid of startup/shutdown code as much as possible, and to make the classes more self-organising as far as their lifetimes are concerned.
Part of that will probably also involve eventually getting rid of the DeletedAtShutdown system, which is pretty clunky and can easily lead to this sort of dependency problem. In your app I’d definitely recommend using ref-counting to manage the lifetime of global or shared objects rather than this. I certainly wouldn’t recommend having an ApplicationCommandManager object that outlives your JUCEApplication class, so the best way to handle that is simply to make it a member of your app class.
You are right with that that, but please please don’t remove the DeletedAtShutdown to early!!! (live is hard enough at the moment, with all the module stuff
yes and no, something like Desktop IS a system component, which is part of an environment which should be present at application-logic code (if it uses a GUI)
ApplicationCommandManager is not a system-relevant component.
Yeah, the situation I’d like to get to would be where all the objects are created on demand and don’t rely on a predetermined startup/shutdown order at all.
