ComboBox popupMenu incorrect positioning

MacOSX and iOS
1

Hello everyone!

The issue arises only when I load my AUv3 plugin in AUM (or other DAW) on iPhone in portrait screen orientation and then switch to landscape screen orientation after loading the plugin. If I rotate the iPhone to landscape screen orientation before loading the plugin, the popupMenu is rendered correctly. Does anyone know what might be causing this?

Problem:

photo_2024-01-20 20.35.01
photo_2024-01-20 20.35.011280×719 84.6 KB

It should be like this:

photo_2024-01-20 20.34.57
photo_2024-01-20 20.34.571280×719 80.3 KB

2

More details: I’m using a custom LookAndFeel and overridden the getParentComponentForMenuOptions method using getTopLevelTargetComponent from the current JUCE development branch

Component* getParentComponentForMenuOptions (const PopupMenu::Options& options) override
{
#if JUCE_IOS
    if (PluginHostType::getPluginLoadedAs() == AudioProcessor::wrapperType_AudioUnitv3)
    {
        if (auto* target = options.getTopLevelTargetComponent())
            return target->findParentComponentOfClass<AudioProcessorEditor>();
        else        
        return nullptr;
    }
#endif
    return LookAndFeel_V2::getParentComponentForMenuOptions (options);
}
3

AUv3 plugins run in a ‘sandboxed thread’ context, where native child sub-windows do not automatically inherit their relationship (context) from the parent window - you have to manually re-attach subwindows to their parents in AUv3.

I ran into this issue myself and our solution was simply to remove the popupmenu as a UI paradigm and replace it with a sliding drawer, which is not only a lot more user friendly in a touchscreen scenario, but also solves the issue of orphaned sub-windows. This may not be an option for you - so what you need to do is work out how to gain the AUv3 main plugin window context and re-associate it with the popup menu child window, so such things as positioning is contextual to the main window. Others have worked this out - do a search for “popupmenu”, there have been some threads about this already 


1 Like
4

Thank you! Yes, this is my Plan B - to avoid using popupMenu and create a custom component with similar functionality. It seems I’ve already tried all the options discussed on this forum, and still, this bug persists.

5

Yeah, I tried all the proposals as well, albeit a bit glibly because eventually I realized that popup menus’ are simply archaic and not as useful on touch as they could be - so we just decided to move to a more functional UI paradigm, the slide-out drawer, which fits in with the rest of the component hierarchy more appropriately. It simplified things immensely and resulted in a better user experience, anyway.

1 Like