LookAndFeel assert firing with ComboBoxPopup open


#1

This is related to LookAndFeel assert firing on 5.2 quit

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?


~LookAndFeel() assertion when used with PopupMenu that's still open
Quitting while popup showing causes assert
#2

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.


JUCE Assertion failure in juce_LookAndFeel.cpp:64 and AudioDeviceSelectorComponent
#3

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?


#4

You could add

PopupMenu::dismissAllActiveMenus();

in your code to make sure the menus are closed when the ComboBox/PopupMenu is destroyed.

Check out the Widgets demo.

Rail


#5

I tried that, but the ComboBoxes get destroyed prior to the assertion firing, and their deconstructor also closes the PopUps with calling hidePopup().


#6

Here is a minimal example which triggers that assertion:


Just load that plug-in into the JUCE plug-in host, click the comboBox and close the plugin-host (e.g. cmd+q on mac).


#7

[EDIT] Okay - I am able to reproduce here… Will check it.

I know Jules fixed this kind of issue from this thread:

Commit:

Rail


#8

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?


#9

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?


#10

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:

MyCombobox::~MyCombobox()
{
getRootMenu()->setLookAndFeel(nullptr);
setLookAndFeel(nullptr);
}

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.


#11

Thanks a lot!


#12

@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.

Update: This still doesn’t solve the problem :-/


#13

Yeah, it seemed to solve it, but then didn’t in other cases.


#14

I am wondering whether there is a solution for this problem?
Inheriting from ComboBox by using ehsanen1’s approach doesn’t solve the problem for me.


#15

This should be fixed on the develop branch now.


#16

Works like a charm, thank you!