The assertion can routinely fire on Linux, where a window may go through
many size changes from (0, 0) to its actual size due to the nature of
how XWindow reports these in subsequent ConfigureNotify events.
These subsequent changes aren't visibly observable by users.
There were a few "ambiguous operator new/delete" errors that were due to
inheriting from a private base class that used the leak detector. These
errors are resolved by adding the leak detector to the derived classes.
JUCE_API was missing from a few useful types, notably the ARA hosting
types.
Previously, MouseSourceState::checkButtonState would trigger a menu item
if the MouseSourceState had observed the mouse button transition from
pressed to released while over an item, after more than 250ms had
elapsed since creating the menu window. In situations where the main
thread was very busy, this timeout could sometimes be reached inside the
same mouse click/release gesture. If the menu was created inside a
mouse-down, then simply tapping the mouse could sometimes trigger an
item from the menu as soon as the menu window appeared.
To help avoid accidentally triggering menu items, the menu window now
prevents any item from being triggered by the mouse until either the
mouse has been released once, or the mouse has moved. Put another way,
if the mouse is initially pressed when the menu is shown, it cannot
trigger a menu item unless the mouse is moved before it is released.
This reverts 515e9b9f89.
In order to avoid recursive calls through WM_NCHITTEST, we remove calls
to Component::contains in DocumentWindow::findControlAtPoint.
For some transforms, the program could get stuck in the following loop:
- The content component emits a resized/moved notification, leading to
the initial call to Viewport::updateVisibleArea.
- New positions are computed for the viewport scrollbars, and scrollbar
listeners are notified synchronously that the scrollbars have been
updated.
- The viewport itself listens to the scrollbars, so it receives a
notification and updates the position of the content component.
- The scrollbar position (quantised to an integer) resolves to a
component position (also quantised to an integer) that differs from
the existing position, so the new position is applied.
- The viewport now attempts to set the scrollbars to the correct
position in response, and notifies listeners that the scrollbars
have moved...
Normally, the recursion would exit at the point where the component position
is set to its current position. If we're unlucky, though, converting
from view pos to scrollbar pos, then scrollbar pos back to view pos may
result in a view pos that differs from the original value.
This fix adds a new exit condition from the recursion. On receiving a
scrollbar move notification, we check whether the scrollbar position
computed from the current view position matches the incoming scrollbar
position. If it does, there's no need to compute and apply a new view
position from the incoming scrollbar position.
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.
