- Add AlertWindow::show() and showAsync() methods that take a MessageBoxOptions argument
- Add NativeMessageBox::show() and showAsync() methods that take a MessageBoxOptions argument
- Update the DialogsDemo to demonstrate the new methods
- Deprecate AlertWindow::showNativeDialogBox() in favour of the NativeMessageBox methods
- Pass button strings specified in MesssageBoxOptions to native dialog boxes correctly
- Use modern TaskDialog on Windows for the native dialog box where available
Ideally, we want to pass shortcut keys to the component to handle, and
only fall back to invoking a menu item if the component was unable to
handle the keyboard event, or if the action was triggered by
clicking/selecting an item in the menu itself. The old implementation
tried to work out whether the action was triggered by a shortcut by
checking the event's characters and modifiers. This method was
inaccurate, because some shortcuts (such as arrow keys) may add
unexpected numpad/function modifier flags.
We now try handling shortcut keys directly in the peer, and pass events
up to the superclass (which will forward them to the main menu) if the
event could not be handled.
This commit also adjusts some Objective-C method signatures to use the
correct string encoding for the BOOL type.
X11 cannot maximise windows that have their maximum size set. When not
using the native titlebar we now revert to setting the window bounds
without involving the X11 maximise function.
Some plugins (Izotope Relay, some older DPF plugins) use NSTrackingAreas
to handle mouse events, but unprocessed events seemingly get passed up
to outer views. Processing these events was causing unexpected
behaviour. For example, if the cursor entered a plugin view while
dragging a JUCE window border, a mouseEnter event was be generated,
interrupting the drag.
We now check whether mouse events were generated by an NSTrackingArea
which does not belong to the JUCE view, and ignore the event in this
case.
This commit also removes the subview from its superview's subview array before re-ordering as the macOS docs don't make any guarantees about what happens when adding a subview that is already contained in the array.
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.
