Whenever a ComboBoxPopup is active and I close the GUI, the weakReference assert is firing. I have this in my GUI’s destructor: setLookAndFeel(nullptr);
I tried using comboBox.hidePopup() before that, yet without success.
Is there something like a global method to close all active popups instantly to avoid this?
Yes, you can do a ModalComponentManager::getInstance()->cancelAllModalComponents().
But generally it’s safer to keep hold of any active modal components by having smart pointers to them in your editor component. That way deleting the editor will destroy them all synchronously as it dies.
Can’t get it to work… when i call ModalComponentManager::getInstance()->getNumModalComponents() in my editor’s constructor it returns zero, even without ModalComponentManager::getInstance()->cancelAllModalComponents(). so i guess all modal components are taken care of.
However, the assertion still fires, whenever I quit the plugin host (coming with JUCE) with cmd+q while a PopupMenu of a PluginEditor’s ComboBox is open. Can anyone reproduce this with a custom LaF?
I did some debugging:
in lldb: p thisLaF.masterReference.getNumActiveWeakReferences()
it returns 1 when the popup is closed, as expected.
it returns 2 when the popupMenu is open, also expected behavior.
directly after cb.hidePopup(), ModalComponentManager::getInstance()->cancelAllModalComponents(); AND PopupMenu::dismissAllActiveMenus(); it also returns 2. not expected.
So maybe there is something async going on when it comes to removing that reference, which never happens as there is no time when closing the GUI?
After some digging I am now more and more positive that the problem is an async update. The refcount is not decreased until the Message Thread has called the ModelComponentManager asynchronously due to a previous call of ModalComponentManager::getInstance()->cancelAllModalComponents(); (or closing the PopupMenu).
So I assume that’s a JUCE bug?
I found 3 threads on Juce forum somehow related to this problem. None of the suggestions in those threads solved my problem. I have a combobox with a customized LookAndFeel. Here is how I fixed it:
in the Combobox’s destructor, I first set the lookandfeel of the popup menu to null and then set the lookandfeel of the combobox itself to null. Now it works like a charm! Hope it can help someone struggling with this issue.
@jules: is that fix something for the ComboBox class?
(Meanwhile) I will copy ehsanen1’s approach, inheriting from ComboBox and applying the fix, but it would be great if it would make it to the JUCE code.