This mirrors the behaviour on Linux, where maximizing a window always
fills the screen, even if a constrainer is active.
If you don't want to allow your component to fill the screen, disable
the maximize button in the window's titlebar when creating the window
(i.e. ensure DocumentWindow::maximiseButton is not set in the required
buttons).
This new factoring is a bit more typesafe, as it avoids casting
internals to void*.
It also allows cursors to scale appropriately on high resolution
displays on Windows.
The scaling machinery in the component peer was causing problems for
hosted plugin views. Scaling the plugin view size requires close
collaboration between the plugin and the host, and it's important for
the host to have exact control over the size of the plugin's view. The
removed code in the HWNDComponentPeer was modifying the sizes of
embedded plugin windows, which would often leave them at an incorrect
size.
The faulty behaviour was especially noticable with plugins that do not
support DPI-aware behaviour. I tested with the following plugins (VST2 +
VST3), which should all now display correctly in the AudioPluginHost,
and assume the correct size when opened on hi-res displays, or dragged
between displays with different scale factors:
- Plogue AlterEgo
- U-He Hive 2
- FabFilter Pro-C
- Native Instruments Supercharger
- Surge
Sometimes, changing the bounds of the window inside the DPICHANGED
handler can cause further DPI change events to be processed. Previously,
the scaleFactor set by the "inner" events was also being used when
notifying listeners about the "outer" events, leading to graphical
glitches.
An effect of the bug was that VST2 views in the AudioPluginHost would
occasionally render with an incorrect size and position after dragging
them between displays with different scale factors.
With this change in place, we only notify listeners and update window
bounds once there are no DPI changes in progress.
- 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
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.
This change makes heavyweight views listen to window events from higher
in the window hierarchy. If a move or resize event from higher in the
hierarchy is encountered, blocking modal components will be dismissed.
This patch should resolve an issue where the popupmenu for a combobox
could become 'stranded' if the plugin window was moved while the box was
open.
In very optimised builds, SHCore.dll may not be automatically loaded
into the address space of the calling executable. In these cases, the
call to `GetModuleHandle` will fail. Adding the call to LoadLibrary
ensures that the dll is loaded into the program's address space, which
will allow the call to GetModuleHandle to succeed.
reuk
ed