AUv2 plugins on Arm that are hosted out-of-process (e.g. in Logic 10.7)
can sometimes crash due to endlessly recursing through becomeKeyWindow.
This tends to happen when displaying a secondary window in a plugin,
e.g. an AlertWindow, then clicking on a secondary app, then clicking
back on the AlertWindow.
To avoid this case, we check that the peer isn't already key before
calling makeKeyWindow.
Unfortunately, we can't use isKeyWindow to avoid the recursion because
this may not return true until after becomeKeyWindow has returned.
The previous method for finding the dialog's owner was ineffective, and
it was still possible for other windows to obscure the file picker in
many cases. Using GetActiveWindow seems to produce the expected
behaviour.
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.
Without this event Components such as Button would remain in a hover
state indefinitely after being clicked on a touch screen. The simulated
event matches the behaviour of the other platforms.
CGContextGetClipBoundingBox sometimes returns a 'null' rect. When it
does, the following logic will get stuck in the while loop drawing
individual tiles over and over again.
Opening some JUCE VST3s in FL Studio's patcher can cause crashes because
of data races on objects accessed from setActive() and process().
According to the VST3 specification, these functions should never be
called simultaneously, so I think this is a bug in FL Studio.
This allows paths that are prefixed with environment variables to behave
as expected. This is useful when scanning the default LV2 locations in
the AudioPluginHost on Windows.
Some hosts (e.g. REAPER) will attempt to instantiate plug-ins with 64
active channels, and JUCE can't represent this layout. In this case,
failing to convert between VST3/JUCE layouts is not a logical error, so
asserting is not appropriate.
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, all parameter changes were routed first into
cachedParamValues. Then, on each audio callback, an update would be sent
to the editor via the parameterDispatcher for each changed value in
cachedParamValues.
Now, parameter changes are immediately added to the parameterDispatcher,
without needing to wait for an audio callback.
