Combobox popup menu appears behind main component


#1

We have made a VST plugin containing combo boxes. When using Reaper as a VST host, the popup menus associated with each combobox are displayed behind my VST gui. Reaper has an “always-on-top” feature for the floating plugin guis, and this seems to be the problem. The plugin editor floats on top of everything, but the popup menu is not added as a child to any editor component and therefore disappears behind.

Is there an easy fix for this? Could the popup menu be a child of the combobox or does that have unwanted side effects?


#2

Did you ever find a solution to this? I’ve got the same issue on Mac, Cocoa, different host.

Thanks


#3

I’m sorry, but we didn’t pursue it any further. For Reaper there is a work-around, since the user can unpin the always-on-top feature, and at the time we found that sufficient.

Sigurd


#4

I’d like to wake this thread back up. I’ve encountered this and another similar problem, not with Reaper but with Samplitude. I have a tester who reports the combo box coming up behind the main GUI. I haven’t reproduced this, but I have found that the combo box is detached from the plugin GUI. If I open the combo box and then drag the GUI elsewhere, the combo box stays where it is instead of moving with the GUI.


#5

I recently had two customers with the exact same issue with combo boxes.
One reported that it happend both in a VST and in a standalone juce exe under Win7, and its almost as if the main window is “always on top”.


#6

The problem, as I understand it, is that the combobox popup is created independent of the combobox component. I assume that making the popup menu a child of the ComboBox could solve this issue, but I haven’t tried to modify the Juce source code to test this. There could possibly be a reason for this implementation that I don’t know of. I have to admit that we’re still using version 1.53, but a quick peek into the latest repository (the method ComboBox::showPopup) indicates that the implementation is the same as before.


#7

Jules, any comments on this?


#8

Well, yes, a combo box’s popup will stay where still when the main window moves… it’s a separate window. But I wouldn’t consider that a problem…


#9

It’s weird and I haven’t seen other combo boxes behave like it. It acts like some sort of odd tear-off, except you tear off the main window instead of the sub window. It should move with the main window.

But then there’s the other more serious problem when the combo box appears under the gui that owns it. It’s been seen on Windows in at least two DAWs. Unless the combo box is large enough to peek out from underneath the main window, it doesn’t seem to be there at all. This may be something particular about the way Windows works, since I’ve never seen this behavior on Mac. These two complaints might be related–I suspect they are–but having a combo box that you can’t see doesn’t seem to be particularly useful.


#10

I think that probably ALL combo boxes work like this, but normally they’ll close when you click somewhere else, so you don’t get chance to see what happens when you move the window. In a host it’s actually very hard/impossible to always catch the mouse events and close it in time, which is why you’re seeing this, but it really doesn’t seem like a big deal to me.

And if it’s behind the other windows, that must be because the host has made its other windows always-on-top. That could be worked-around by making the popup menu windows always-on-top too, but it’d need some logic to work out whether or not it needs to do this, by checking whether there are any other always-on-top windows active.


#11

If we make the combo pop up always on top, can we make it more on top than the VST window always on top?


#12

Apparently quite a few people select this always-on-top option–enough that the problem bounces back to us. Jules, it appears that you have your reasons not to make changes in the code. Do you have a workaround for the current incarnation of code, or am I going to need to get in there and do a hack?


#13

It’s very easy to hack, but I’m not sure exactly what the correct solution would be - making it always-on-top is bad in some apps, but needed in cases like this.


#14

I don’t know about always-on-top. That doesn’t sound any better than DAWs that do it. I think I’d be satisfied if it maintained the same relationship in the Z-plane, ie on top of the main GUI.


#15

Huh? If the host has an always-on-top window, the only possible way to get in front of it is to also be always-on-top.


#16

Huh? If the host has an always-on-top window, the only possible way to get in front of it is to also be always-on-top.[/quote]
Let me back up and take another run at it. My GUI window is composed of many components–a background image, and several components that are drawn on top of it. Those components are attached to the main component in the order I wish them to appear in the Z-plane. Those which are made children last appear closer in the Z-plane and are drawn on top of the other components…

…Except for combo boxes in this windows situation. Even though they’re made children later (and should appear on top of older items), they don’t in this case. But all other components in the GUI still appear in the proper order. How come they do and combo boxes don’t?


#17

So you’re talking about the combobox itself, not the popup it creates?


#18

I’m talking about the popup (sorry not to be clear). In the ‘normal’ case, the popup appears on top of the GUI. In the degenerate case, it appears behind the GUI (even though all other elements remain in their appropriate positions).


#19

Right, so if you’re talking about the popup, then that’s what I was talking about before… What else can I say?


#20

I’m not really sure how you defend it, but at this point I’d be satisfied for a pointer to where I need to go to recode it.