Yeah, that sounds likely. Async is the future, man!
That's not the solution unfortunately... I spent a lot of time chasing this.. and came up with a solution which worked for the Juce Demo host but didn't work for other hosts... I have a working solution (but not one Jules would be happy with).
Rail
I noticed the same issue in reaper x32 on Windows. It happens if i open the plugin in his own plugin window without the FX Stack on the left. It seems to work if the plugin is embedded in the FX window. Popup menus work as expected.
Any help would be great!
Our testers wrote about the same issue in Samplitude. After some investigation it seems, if DAW sets VST plugin window as "always on top" the combobox popup menu and right-click context menu both are behind the plugin window. It can be reproduced even with VST plugin analyzer. This tool http://www.pcworld.com/article/218511/Windows.html can be used to set VST plugin analyzer window as "always on top".
Some more details:
1. The same "popup menu appears behind" effect can be reproduced without setting the plugin window as "always on top", if this line is commented out:
class MenuWindow : public Component
{
public:
MenuWindow (const PopupMenu& menu, MenuWindow* const parentWindow,
....{
....
//setAlwaysOnTop (true); <-- this
2. Next problem. JUCE mouse handlers can't be used as filters, e.g. _each_ mouseDown() handler is called and our mouseDown() handler, which called the 1st in the chain can't stop further mouseDown() handler calls.
void Component::internalMouseDown (MouseInputSource source, Point<int> relativePos, Time time)
{
....mouseDown (me); // <-------- our handler, which opens popup menu on right mouse click
....
desktop.getMouseListeners().callChecked (checker, &MouseListener::mouseDown, me);
//MouseListenerList::sendMouseEvent (*this, checker, &MouseListener::mouseDown, me); <-- this
}
If sendMouseEvent() call is commented out, popup context menu always opens correct on right mouse button click even in "always on top" case.
3. The guilty line is here in juce_VST_Wrapper.cpp:
#if JUCE_WINDOWS
void mouseDown (const MouseEvent&) override
{
broughtToFront();
}
void broughtToFront() override
{
// for hosts like nuendo, need to also pop the MDI container to the
// front when our comp is clicked on.
if (HWND parent = findMDIParentOf ((HWND) getWindowHandle()))
SetWindowPos (parent, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
}
#endif
It means, _after_ each mouse click on plugin window, this broughtToFront() call is used to put the window on top again and thus popup menu is behind it.
We replaced #if JUCE_WINDOWS to #if 0 and now the effect has gone!
Unfortunatelly, according to the comment above we may have problems with Nuendo but let our testers to check this.
Ok, I see, thanks for the detailed description.
The code can't be removed because it obviously does serve a purpose on some hosts, but perhaps it could be tweaked so that it doesn't bring it to the front unnecessarily, e.g. does this work?
if (! isCurrentlyBlockedByAnotherModalComponent())
if (HWND parent = findMDIParentOf ((HWND) getWindowHandle()))
SetWindowPos (parent, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
?
It works for me! Thank you.
I am running into this old bug again, on Cubase 7.5, running 64-bit VSTs in OS 10.9 and 10.10. It happens with both my ComboBox items and PopUpMenus. Interestingly enough, the issues I used to have in Reaper with my 64-bit VSTs have been fixed (by some code changes in the past few years), and the issues don't show up for me when running Cubase 7.5 in OS 10.6 or 10.8.
I am unable to verify that the menus are showing up behind the plugin window. However, if I have the mouse over one of the ComboBoxes or PopUp menu, and I hit Command+Q, the menu will then show up.
Any idea of how to fix this? I'm not concerned about whether or not something is proper modal or non-modal behavior in non-plugin circumstances. All I am concerned about is how to fix it for plugins. This is all I use Juce for.
Thanks,
Sean Costello
The menu windows are already set to be always-on-top.. And if you look inside PopupMenu::showWithOptionalCallback(), you'll see I've already done a lot of stuff to try to force it to the front. Not sure what else I could do if the host is being awkward, but if you can find something that works in this particular OS/host combination, let me know!
I think the root of this problem is the fact that combo boxes are separate and independent windows. To maintain the 'traditional' way they work, it's necessary that they be different sizes: the most typical combo box may be a strip that is vertically larger than the main plugin window itself. With all of the different DAWs, it seems that keeping all this stuff properly stacked in the Z-plane is nearly impossible. I know Jules has returned to this time and time again.
My solution might not work for everyone, possibly for matters of taste or because of the size of their plugin windows. I wrote my own pseudo-popup manager that lives in the main plugin window. It's just a component that's made visible when a user hits a button. I had to write appropriate mouse-capture stuff to select items and also some messaging to get the selection back to the editor. It's tied in to other aspects of the way I do things, so it's not something I'd put back into the Juce mainstream. But a similar approach might work in a more generic way.
In most cases--when there aren't too many members--it looks exactly like a plain old combo box. if it needs to offer more selections, it expands horizontally (always staying in the bounds of the plugin window) and in the worst cases offers left/right buttons to move around. And of course it's always on top of the plugin window because it belongs to the window.
Sean,
I sent you a PM… I have a working solution which subclasses the ComboBox and PopupMenu classes and uses a modal popup… The only issue is there’s a tiny benign leak in the MouseInputSource class deep in the JUCE bowels if you quit while a popup is open.
I tested it in Reaper, Pro Tools and Cubase and it seems to work well.
Rail