PopupMenu options not set correctly for child sub menu

If I use in my LnF the target component to have a custom per menu LnF then it stop working as soon as I have child/sub menu
in bool showSubMenuFor (ItemComponent* childComp)
The target component is reseted.
Is there a rationale for this ?

just using

            activeSubMenu.reset (new HelperClasses::MenuWindow (*(childComp->item.subMenu), this,
                                                                options.withTargetScreenArea (childComp->getScreenBounds())
                                                                       .withMinimumWidth (0),
                                                                false, dismissOnMouseUp, managerOfChosenCommand, scaleFactor));

Fix my issue.

Thanks !

sounds good ?

I’m not sure without spending some time investigating, but it looks to me like that line (withTargetComponent (nullptr)) has been in place since 2011 - I’d be quite surprised if it served no purpose and we were only discovering it now…

I have release a version with this code and didn’t notice any issue FWIW

I believe this line makes sense for a submenu. If the submenu were to inherit the exact same options of its parent menu, then the submenu would appear at the same topleft position of the main menu, but that’s not what is usually desired: the desired behaviour of the sub menu is to appear right next to the item in the main menu that opens the sub menu.

For example, if the target component of the main menu is a button, then the main menu appears next to the button. Any sub menu for the main menu should not appear right next to the same button, but should appear at the correct position next to the main menu.

This is not what happens if you remove this line though :slight_smile:

Ahh, you’re right, because withTargetScreenArea (childComp->getScreenBounds()) overrides the target area anyway.

So, you want to retain information also in the sub menus about the component that was originally targeted by the main menu.

That seems a valid expectation, and the documentation proves that having both a target component and a target screen area is valid and well defined (emphasis mine):

For withTargetComponent():

This function will also set the target screen area, so that the menu displays
next to the target component. If you need to display the menu at a specific
location, you should call withTargetScreenArea() after withTargetComponent().

For withTargetScreenArea():

withTargetComponent() will also set the target screen area. If you need
a target component and a target screen area, make sure to call
withTargetScreenArea() after withTargetComponent().

So your request for the change (albeit breaking) looks totally valid to me

The thing is that without this fix, all the new withOptions LnF additions in order to have LnF that depends on the target component get pointless as soon as your menu have sub menu.

1 Like

Bump :slight_smile:

2 Likes

Bumpity bump :slight_smile:

1 Like

Would love to see this getting fixed. Without this all the new withOptions LnF are useless.
FWIW I have release a product with my included fix and never add any issue. I would just like to avoid to fork Juce just for this.

Thanks !

1 Like

Obi-Wan Kenobi, you are my only hope.

1 Like

does the trick.

Thanks !

Sorry for the lack of updates. I think I didn’t really get back into the swing of things after ADC!

As you pointed out, a fix was added on develop that allows the original target component to be retrieved from submenus. This behaviour is opt-in (i.e. you must call getTopLevelTargetComponent()) to preserve the behaviour of the existing getTargetComponent().