This also fixes a bug introduced in f7c7225f5c
where the condition guarding the definition of traitCollectionDidChange
was incorrect. This function is never required if the deployment target
is at least 17.0.
This reverts 515e9b9f89.
In order to avoid recursive calls through WM_NCHITTEST, we remove calls
to Component::contains in DocumentWindow::findControlAtPoint.
This partially reverts commit 555b667d22.
Using ComponentPeer::isShowing instead of ComponentPeer::isMinimised
inside Component::isShowing can cause problems when displaying OpenGL
components.
Specifically, OpenGL components use a ComponentMovementWatcher to
determine when they should be attached/detached from the parent window.
The ComponentMovementWatcher updates whenever a component visibility
change event is emitted, which happens in two cases:
- Component::setVisible is called on the OpenGL component or an ancestor
- ComponentPeer::handleMovedOrResized is called in response to a
minimisation state change
When handling either of these events, the ComponentMovementWatcher will
call Component::isShowing to determine whether or not the component is
really showing.
The problem is that the result of ComponentPeer::isShowing may change
independently of changes to the Component visiblity state or
ComponentPeer minimisation state, so the ComponentPeerWatcher might not
notify its listeners when a component is really shown/hidden.
One potential workaround would be for the ComponentPeer to send
notifications when the showing state of the window changes, so that the
ComponentMovementWatcher can forward those notifications. The main
problem with this approach is that on Windows, the window doesn't seem
to receive a message on hide/show, and it's not clear whether there
exists some other approach to detect a hide/show event.
If there were some event we could listen for on Windows, then we could
call Component::sendVisibilityChangeMessage in response to this event
and things would *likely* work at that point, but this may still have
unintended side-effect. As a result, I think the best approach to
restore the old behaviour is to revert the change to
Component::isShowing. The implementations of ComponentPeer::isShowing
have been left in place so that users can do still query the real
visibility state of native windows if necessary.
toWideCharPointer() returns a pointer to a buffer managed by the String.
The wchar_t pointers are not read until the invocation of
TaskDialogIndirect, so the String instances must remain alive until this
point.
Previously, maximising a frameless window on a secondary display could
result in the window's coordinates being computed incorrectly, leading
to graphical glitches.
The docs for WS_MINIMIZEBOX and WS_MAXIMIZEBOX specify that WS_SYSMENU must be specified.
The docs for WS_SYSMENU specify that WS_CAPTION must be specified.
From Windows 10 onwards, the window under the mouse will receive
WM_MOUSEWHEEL messages regardless of focus state, so this hook appears
to be unnecessary.
- Required when the deployment target is macOS 15+
- As the ScreenCaptureKit framework isn't available on all supported versions
of Xcode it's dynamically loaded
When handling WM_NCCALCSIZE, we reduce the size of the client area when
the window is maximised. If we don't do this, then the client area
matches the top-level window area, which is larger than the display's
safe area. As a result, the window appears too large, and the edges are
obscured under the edges of the display.
After reducing the client area in WM_NCCALCSIZE, the client area is no
longer equal to the top-level window area, so getBounds() must be
updated to return the window's *client* area rather than the top-level
window area.
