We have a plugin that has a combobox (NOT using any parameter attachment), for which we set its index to 0 at the end of the constructor. If the user opens the editor and then immediately closes it, it crashes.
This appears to be because the setting of that index triggers an asynchronous update, which is processed after the view component’s destructor has been called, causing the component’s onComboBoxChanged() function to be called, with an invalid object for the combobox. It’s a reference-counted object (std::unique_ptr), so I can’t simply check for nullptr, and the reference count shown in the debugger is garbage, so that’s no help, either.
How can I prevent this crash (other than telling users “Don’t close the editor that soon after opening it!”)?
It’s in your code or juce own code ?
If this is in your code, you can store your widget in
juce::Component::SafePointerjuce::Component
and check it’s still valid.
By the way, this is with JUCE version 5.3.2.
I don’t know how that would work. The editor has been destroyed, and yet the asynchronous message still arrives in the sub-view’s comboBoxChanged() function. It’s the parameter to that function (comboBoxThatHasChanged) that is no longer valid, and I know of no way to check if it is still valid. Once the editor has been closed, nothing in any of its components is valid any more, so where would I store anything that I could check?
It seems to me that this is a design flaw, in that the asynchronous update is still propagated to the editor that has already been closed. It should be prevented at some higher level from calling a no-longer-existing editor or its components.
I can prevent the crash by NOT setting the selected item index from the constructor, but then the drop-down does not have its default item selected when first opening the editor.
Looks like I can simply pass dontSendNotification to setSelectedItemIndex() when setting that from the constructor, and it will no longer crash. Since this is just a default setting, and since the processing code also defaults to that same setting, it looks like we don’t need to be notified of the change at all.
This is quite weird as combobox uses AsyncUpdater for that which disabled the notification when destroyed.
Maybe it was a bug in this older version (5.3.2)? In any case, not allowing any notification from this particular call seems to prevent the problem.
