I think it would still be cool to have a ComponentListener::componentIsBeingDeleted() method. The way the ComponentDeletionWatcher works internally is pretty foolproof (well, 99.99999999%) but it would still be cool to be able to get notified synchronously when a Component gets deleted. It wouldn’t cost anything to integrate this.
actually, after my initial embarrassment ComponentDeletionWatcher is not quite how I’d like to do it so … still +1 from me on ComponentListener::componentIsBeingDeleted() !
A slightly different request, but not incompatible, I think:
At times, I would like that the ComponentDeletionWatcher would be able to deal with NULL pointers, that is if I supply it a NULL pointer, it does not crash but would just return 0
I would say it should return “true” (if “hasBeenDeleted” is read as “isNotAValidComponent” ) – also the rule is simple: getComponent returns 0 if and only if hasBeenDeleted is true.
While thinking of it, another request would be to have a constructor taking no arguments (initializing the watched component with NULL), and being able to watch a component for deletion after construction with something like ComponentDeletionWatch::watch(Component *c) {…}
That would be also very handy, for example when one declares a ComponentDeletionWatcher as a member variable in a class, but cannot initialize it immediatly in the constructor.
I too think ComponentListener::componentIsBeingDeleted() would have come in very handy.
When interfacing to PILS, I had a tough time finding out how to deal with deleted components. A deletion notification would have saved me some heavy hair pulling, and might make life easier for others that want to experiment with scripting.
If you decide to add it… perhaps it could be arranged so that it is called after the component being deleted has deleted those of its child components it wants to delete. A listener could then delete any remaining children; IMO the delete-all-children scheme works better with dynamic languages than the one implemented in Juce.