Previously, MouseSourceState::checkButtonState would trigger a menu item
if the MouseSourceState had observed the mouse button transition from
pressed to released while over an item, after more than 250ms had
elapsed since creating the menu window. In situations where the main
thread was very busy, this timeout could sometimes be reached inside the
same mouse click/release gesture. If the menu was created inside a
mouse-down, then simply tapping the mouse could sometimes trigger an
item from the menu as soon as the menu window appeared.
To help avoid accidentally triggering menu items, the menu window now
prevents any item from being triggered by the mouse until either the
mouse has been released once, or the mouse has moved. Put another way,
if the mouse is initially pressed when the menu is shown, it cannot
trigger a menu item unless the mouse is moved before it is released.
This allows the LookAndFeel of submenus to query the target component
used for the top-level menu. getTargetComponent() isn't suitable for
this because the target component is set to null for submenus, and this
behaviour can't be changed without potentially breaking code that relies
on the current behaviour.
In cases where no JUCE component had keyboard focus, clicking a menu
item would cause the menu to be dismissed instead of triggering the
item's action.
- Created a new detail namespace
- Moved shared module implementation details into the detail namespace
- Split dependencies so source files only rely on details in the detail namespace
- Removed all code from the juce_gui_basics.cpp file
Without this VoiceOver will iterate over menu items left to right first,
and iteration order will be affected by whether the PopupMenu gets
broken up into multiple columns due to not enough screen space.
Previously, for the following snippet, the menu's LnF was incorrectly
being forced to the default LnF. The correct behaviour is to display the
menu using LnF v4. The menu doesn't have an explicit LnF set, so it
should use the LnF of its parent component.
LookAndFeel::setDefaultLookAndFeel (&lookAndFeel_V1);
setLookAndFeel (&lookAndFeel_V4);
PopupMenu().showMenuAsync (PopupMenu::Options{}.withParentComponent (this));
Previously it was possible to inadvertently activate a menu item by
clicking on a submenu item that was drawn on top of the parent menu.
The root cause was that hide() initiates an asynchronous mechanism
through exitModalState() that eventually destroys the MenuWindow, but
the MouseSourceState timer callbacks and event handlers sometimes still
had a chance to do a state update. Since the submenus have just been
destroyed the update could mistakenly conclude to activate one of the
items of the now lone parent.
The 'wrapper' accessibility handler is now ignored if a menu item has a
custom component, and has no submenu, and cannot be triggered
automatically. This avoids the case where a custom menu item may end up
with a wrapper accessibility handler that has no useful actions.
This patch also adds a 'label' argument to the addCustomItem functions,
which allows text for the screen reader to be supplied in the case where
a custom component is in use, but the menu item has accessibility
actions.
This change is designed to fix issues with views stealing focus and
being brought to the front when popup menus are dismissed.
To test this behaviour:
- Open two instances "a" and "b" of a plugin editor containing a
ComboBox
- Click the ComboBox in editor "a", opening its PopupMenu
- Drag the titlebar of editor "b" to move it
- The PopupMenu should be dismissed, but editor "a" should *not* steal
keyboard focus or be brought to the front
When bridging 32-bit/64-bit plugins on Windows, the plugin is hosted in
an auxilliary process, and the plugin's editor is embedded into an HWND
owned by a different process (the plugin host).
Previously, the `isForegroundProcess` check would fail for bridged
plugins, because the foreground window may belong to the DAW, rather
than to the auxilliary hosting process.
This patch adds an additional check, to find whether the same process
owns both the foreground window, and the window which embeds the
PopupMenu's target component. In this case, we avoid immediately
dismissing the PopupMenu.
Adds a new `drawPopupMenuBackgroundForOption` member function to
`PopupMenu::LookAndFeelMethods`. By default this will pass through
to `drawPopupMenuBackground`, but it can be overridden in cases
where the background appearance depends on the current `Options`.
