I have been fooling around a bit with the concepts of Owners and Parents in component/window hierarchies and the other day I stumbled on this example from the Demo application.
The WidgetsDemo demonstrates (MiscPage) how a component may be dragged onto the desktop and become a window. This removes the component from the DemoPageComp child list and adds it to the desktop instead. When the WidgetsDemo is deleted the DragOntoDesktopDemoComp is not deleted since it is not in the child list.
I suppose you (Jules) have noticed this since DragOntoDesktopDemoComp::mouseDrag(…) includes a check that will delete the instance in case its parent is not a valid component.
By opening and closing the WidgetsDemo and dragging the little “bubble-windows” onto the desktop, it is possible to create arbitrarily many instances of the DragOnto… component and leave them on the desktop, and they are not deleted explicitly at shutdown. (You will get an exception in Desktop’s destructor).
There are several ways to deal with this, but my question is:
How do YOU propose to deal with components that are owned by a component of which they are not children, supposing that the deletion of the owner should cause these owned components to be deleted?
Well yes, I know that the demo does that, but don’t really care, as it’s just a demo.
Not sure I understand your question though… Components aren’t any different from other kinds of c++ object when it comes to deciding on ownership and when things should get deleted.
Well, sure - there are numerous way to do this and it can easily be coded according to the desired behavior.
One way is to make a subclass of a Component that contains a collection of owned Components to be deleted as the owner is destroyed.
I was just wondering whether there were already any mechanisms built into the JUCE-framework for handling ownership.
I was also wondering whether a call to deleteAllChildren(…) or something similar would be appropriate in Desktops destructor, rather than just doing an assertion.
My intention was just to ask whether ownership management was an integral part of the design or not.
well it’s rare that you’d actually face such a problem; generally if a component ‘owns’ another one, it’s going to be a child of it. if not, it’s held as a pointer and will probably be a child at some point. and then of course there are the times when you’d want to place it on the desktop.
There’s not often much call for lots of on-the-desktop components, so there’s no built in system for tidying them up - it’s totally easy enough to just destroy any such ‘owned’ components in your destructor. if you do happen to have a program that employs lots of them, then naturally you’ll probably want to have an array of some kind to hold them, and then destroy them all from that.
Ownership is such a nebulous concept, there’s no one-size-fits-all solution that I can think of… Maybe using ReferenceCountedObject on your components would work?
