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.
This change ensures that popup menus will be dismissed when hosted
plugin windows are moved, even when these plugin views are themselves
hosted inside JUCE views, like those used in the AudioPluginHost.
When drawing a popup menu for a target component with a non-unity scale,
the contents of the component were being drawn with an unwanted vertical
offset.
This fixes a regression introduced by
6e9261ea66 which meant that components
were not given a chance to respond to shortcut keypresses if those same
keypresses were registered for a menu item. This resulted in behaviour
where shortcuts such as 'cmd+c' would not be passed to a focused
TextEditor if a different command with the same shortcut was registered
in the main menu.
With this change in place, we now check whether the menu item's shortcut
keys match the current event's pressed keys. If the keypresses match, we
can assume that the event was triggered by the keyboard, and dispatch
the keypresses to the ComponentPeer. If the keypresses do not match,
then the menu item was likely selected using space/return, or by
clicking, in which case the event is dispatched directly to the
ApplicationCommandManager.
This resolves a regression which was introduced in
74ca3b44c4.
Prior to that commit, drag and drop on Linux/X11 worked as expected.
DragAndDropContainer::performExternalDragDropOfFiles allowed dropping
files onto other applications.
After the faulty commit, this function may cause the window manager to
enter a bad state in which the drag operation never finishes, making it
impossible to switch between windows or close windows.
I think the issue happens because the DnD source may receive (spurious?)
XdndLeave messages during the drag, which cause the peer's entry in the
dragAndDropStateMap to be removed. Before the faulty commit, each peer
had its own drag and drop state object, which was not destroyed in this
way.
This change will keep the peer's drag state object alive, even when an
XdndLeave message is received. The entry will still be removed when the
peer's window is destroyed.
IFileDialog::Show and CoUninitialize both seem to require the main
message loop to be active and running when they are called. If we block
the message thread while calling these functions, we may cause a
deadlock.
The destructor of the Win32NativeFileChooser was blocking the message
thread until the background thread exited, but the background thread was
unable to make progress while the message thread was blocked.
To work around this issue, we now pump the message thread in the
destructor of the Win32NativeFileChooser. If a dialog is currently
active, this should allow it to exit gracefully.
Note that we cannot use MessageManager::runDispatchLoopUntil here:
- MessageManager::runDispatchLoopUntil will not process any messages if
the quit message has been received, which could lead to deadlocks if the
FileChooser is destroyed after the quit message has been posted.
- This function isn't defined when JUCE_MODAL_LOOPS_PERMITTED is disabled.
reuk
ed
Tom Poole