ComboBox menu position

I have a fix locally, but Jules wouldn’t approve of my methods :slight_smile:

Rail

You can duplicate this using the JUCE Host… check out my video… which uses the JUCE Demo Plug-in with an added ComboBox in the JUCE Host.

Cheers,

Rail

Yes, but I also want to make sure I don’t break anything else in other popular DAWs.

This is a real nasty one to fix. Can you send me a link to the fix that you have locally?

You have a PM.

Cheers,

Rail

Yeah I see why Jules didn’t like that one. To be honest this is a really tough bug where I’m not even sure if a fix is possible. There is simply no easy way to get a callback when the host window is being live-moved around (or a callback when the title bar of a host window is clicked).

I think the only way to deal with this is to not create a top-level native window for the popup menu. For example, this would fix your issue:

class MyEditor : public AudioProcessorEditor,
                 private LookAndFeel_V4
{
     MyEditor (MyAudioProcessor& owner)
      : AudioProcessorEditor (owner)
    {
        setLookAndFeel (this);
    }

    Component* getParentComponentForMenuOptions (const PopupMenu::Options&) override
    {
        return this;
    }
};
1 Like

@fabian did anyone ever come up with a better fix for this? The proposed solution here doesn’t really work because it forces the popup menu within the bounds of the plugin window. Is it not possible for JUCE to provide access (e.g. via the Desktop class) to a global event hook for mouse clicks so we can programmatically determine if a click happened outside any component in our plugin or application?

Apologies to drag up old thread-within-a-thread…

Is there a workaround for this?

(I tried a quick hack to use showMenu() instead of showMenuAsync() but the menu would only open once then not re-open when clicked.)

Many thanks in advance.

Anyone have anything on this ProTools crash?

@Rail_Jon_Rogut would you be happy to share your fix?

Thanks