My plugin acts as a host for other plugins. The editor keeps a ScopedPointer to a PluginWindow (subclasses DocumentWindow) that in turn keeps a scoped pointer to the sub-plugin's editor and calling setContentOwned(subPluginEditor) . The problem I'm having is ensuring that the PluginWindow is closed, and that the corresponding sub-plugin's editor is always destroyed before the sub-plugin itself. The sub-plugin is destroyed when the host plugin hosts a new plugin. This happens when a user clicks a new plugin in the GUI, or when the DAW (host of the host) loads a new preset that contains a different subplugin.
When a user selects a new sub-plugin to host through the GUI, I can handle this easily by destroying the previous sub-plugin's editor in the editor code before calling the AudioProcessor method that destroys the sub-plugin instance. However, when the need to close the PluginWindow originates from the AudioProcessor, things are not so simple. I can think of three potential solutions but am not sure which one is best.
1) Write a get GetMyAudioProcessorEditor() method in the AudioProccesor class which calls getActiveEditor() and casts the result to MyAudioProcessorEditor. Inline a function to call closeWindow() on the MyAudioProcessorEditor.
2) Call subPlugin.getActiveEditor() and set this to a nullptr in the AudioProcessor. The problem here is that the PluginWindow is now owned by an object that has been destroyed. PluginWindow could implement Timer and periodically check whether its owner == nullptr and close itself if this is the case. This seems extremely sloppy.
3) Make AudioProcessor a ChangeBroadcaster and add the AudioProcessorEditor as a listener right before returning it in the createEditor() method. However, ChangeBroadcast messages are asynchronous. This call cannot be asynchronous because I have to be certain that the sub-plugin editor is destroyed before the sub-plugin itself is destroyed. I read the docs for ChangeBroadcaster::sendSynchronousChangeMessage() and MessageManager::callFunctionOnMessageThread() but I'm not sure its possible or advisable to access message thread in the AudioProcessor.
People who have written plugin host plugins, how have you managed this issue?
Thanks in advance!
Doron