BR: PopupMenu::Options::withTargetComponent not consistent with PopopMenu::showAt()

General JUCE discussion
1

I switched one of my modal loop menus from showAt(Component*) to the async version, showMenuAsync(options). I set options.withTargetComponent(Component*) to the same button but it positions the menu differently. The original places the menu just below the button, using the same X as the button, as one would expect. The async version places the menu based on the mouse click, seemingly disregarding the Component I asked it to attach to…and it just doesn’t look right.

Can we get this corrected please?

2

Works just as expected here. Menu X is the same as button X. Do you use JUCE 6 or 7?

3

Still on a (relatively late) Juce 6.

4

We’re on the latest 6 master version. If you’re not quite there, maybe that’s it?

5

I just updated to the latest June 7 on develop and I get the same issue. See attached.

Also, in the async version, it seems that the menu placement changes depending on where the app window is on screen and mouse location. With the non-async version, menu placement is consistent regardless of window placement or mouse location.

popup bug1
popup bug11461×673 141 KB

popup bug2
popup bug21435×675 140 KB

6

This works for me

menu.showMenuAsync(juce::PopupMenu::Options().withTargetComponent(menuButton), ...
7

It was (obviously) my incorrect usage…

My original usage (doesn’t work correctly):

juce::PopupMenu::Options options;
options.withTargetComponent(&menuButton);
menu.showMenuAsync(options);

Corrected:

menu.showMenuAsync(juce::PopupMenu::Options().withTargetComponent(&menuButton));

Thank you.

8

Hi Ray,

now I see it too. By writing options.withTargetComponent(&menuButton); you create a new object, but never use it for anything. I think it might be a good idea for the JUCE team to add [[ no_discard ]] for these helper functions, so your previous attempt would result in a compiler error.

Regards,
Mike

3 Likes