when I open a ComboBox popup menu and start moving the plug-in window via title bar, the menu stays open and keeps its old position.
I’m using Juce 1.53 and this happens on MacOSX and Windows in VST and RTAS. Although this is not a serious bug, it looks very nasty.
I tried to simply close the menu when the window title bar is clicked, but there are no mouse events coming through.
Does somebody have the same problem?
As our fearless leader would say, use the trunk, luke !
If you’re using ComboBoxes or modal popups in a plugin, you definitely need to move to the latest code, because that way you can use the newer non-modal async menus and combos. Any old code that runs a modal loop is incredibly unsafe in a plugin environment, because if the host closes the plugin while a modal loop is running, your stack can’t unwind, and the results are horrific.
This is fixed in Juce 2.0? OK, I guess it’s time to move things over…
No it’s not fixed, I downloaded the latest version (2.0.27) and the problem is still there.
In an app, it’s possible to override some window functions to find out when the user clicks on the title bar - but in a plugin, the window belongs to the host, not the plugin, so it’s not hackable… I don’t know of any way this could be fixed.
As far as I can understand, the current popup menu shuts down when the user clicks outside the plugin window, as the plugin window looses its focus,
or when the user clicks in the GUI area, as one of the components receives a mouseDown and so gets the focus.
However in the case the user clicks in the plugin window but outside the GUI area (which is the case of the title bar), nothing happens and the menu remains opened.
I have tried to show the popup menu synchrounously (call to showMenu instead of showMenuAsync) in the comboBox and so far it has worked pretty well. What’s the problem with using synchronous popup windows?
I don’t have this problem. I can’t close the host with the modal loop running, since the modal state goes away wherever I click.
No - the modal state goes away after you click. Think about it: if your plugin is running a modal loop, and within that, there’s an event call to the host in which the host deletes your plugin, the stack can’t unwind until after the event call returns, by which time your plugin has already been unloaded from memory.
I understand what you mean. In my case the comboBox are just simple audio parameter controls so I can’t see how this could happen.
Doesn’t matter what it is! Any kind of modal loop at all is unsafe, end of story!
Sorry to drag up an old thread, but it is relevant!
We're experiencing crashes in Pro Tools (AAX) on Mac with comboBox.
1. Insert 2 plug-ins;
2. Open the comboBox on one plug-in;
3. Without closing the comboBox click on the 2nd plug-in in the insert slot, plug-in GUI opens...
4. Pro Tools crashes instantly.
Now, if I change showMenuAsync to showMenu the crashes don't occur, but this is apparently unsafe. With showMenu the comboBox on the first plug-in closes on the first click outside of the plug-in window, so requires two clicks to open the 2nd plug-in, whereas it required one click with showMenuAsync.
Is there a way to replicate the showMenu behaviour whilst retaining the safety of showMenuAsync?
I can't seem to be able to reproduce the crash (OS X 10.10, ProTools 64-bit). See the following video.
The crash was specific to Pro Tools. I say "was" as Rail Rogut from this forum sent me some source code this morning that has fixed the problem! With Rail's code the comboBoxes close as soon as you click outside of them, so there's no way they will still be visible when opening another plug-in.
sorry for the typo, I meant ProTools (not logic) of course. See the video that I posted.
Thanks for posting the video - it would appear that we're doing something wrong in our comboBox subclass!
I will have to check our implementation...
We have found the source of the problem - it's the Juce LookAndFeel_V3 class! After some exhaustive trial and error, help from Rail Rogut and yourself, we realised that the crash was not directly related to the comboBox class itself. Since we changed our SSLlookAndFeel class to inherit from LookAndFeel_V2 the crash no longer occurs.
We haven't yet had time to dig into LookAndFeel_V3 to find the source of the issue, but for now we're up and running!
Is there already a way to fix this issue? It’s quite annoying to have the popup menu staying at the same position when dragging the plugin window…
Doesn’t the popup just close when clicking anywhere outside of the popup?
Nope… only if you click inside the plug-in UI
It’s bank holiday weekend in the UK here and I don’t have access to all the DAWs for testing. I’ll look at this first thing tomorrow.