Use the same 100 DIPs as in wxMSW, to make the default behaviour more
useful.
Also update documentation to explain which size component should, and
should not, be specified when creating the slider.
Closes https://github.com/wxWidgets/wxWidgets/pull/2012
Relying on "check-resize" to detect when a "size-allocate" is in progess is
insufficient, resulting in the possibility of a window ending up with the wrong
size or position after inital layout. Using our existing "size-allocate"
handlers should be enough to detect the cases we care about.
See #18865
A virtual wxListCtrl with wxLC_HRULES which wasn't fully visible on
screen, i.e. didn't fit into the visible area of its parent window
(which included the case when the parent was a wxScrolledWindow, for
which it is normal and expected not to be able to fit all of its
children) got into an infinite repaint loop because of a RefreshRect()
call inside wxListCtrl::OnPaint().
Fix this by avoiding to call RefreshRect() added in 374db28747 (Fix
wxMSW ListCtrl drawing of horizontal rules for new items, 2016-05-04),
unless the current clipping rectangle is less than the actually
effective visible width and not the full client width, which can be much
bigger.
This still doesn't ensure that we don't enter into an infinite recursion
here, so it would be even better to call RefreshRect() at most once
before the next control change, but it's not clear when exactly this
"already refreshed" flag would need to be reset.
See #17158.
Closes#18850.
Don't bother trying to refresh areas beyond the visible part of the
window: not only it's useless, but it also results in debug warnings
from Cairo/pixman due to the use of negative rectangle width/height.
Closes#18848.
Make sure we are not neglecting the layout insets, for controls like
button, choice and gauge, otherwise client sizes became larger than
control sizes.
Closes#18717.
Use custom subclass for native static bitmap, to ensure that we call
wxOSXCocoaClassAddWXMethods() for it.
This notably allows to get mouse click events for this control.
Closes#18545.
We must always change the text colour when using non-default background
colour, as otherwise the text may become unreadable in some themes,
which was exactly what happened in the standard "High contrast" theme
when using wxAUI under MSW before.
Closes https://github.com/wxWidgets/wxWidgets/pull/1989Closes#18832.
This was recently broken in 3bcbc8fe8e (Implement dismissal for
unfocused wxPopupTransientWindow, 2020-07-09) as the changes in it
resulted in the popup being dismissed as soon as it was opened with a
mouse click.
Fix this by changing several things:
- Check for wxCurrentPopupWindow before processing the message, not
after, as the message handler itself could create a new popup and we
definitely don't want to dismiss it immediately after its creation.
- Check for mouse DOWN events only, not UP and DBLCLK ones, as otherwise
it might be possible that UP matching the same DOWN whose handler
showed the popup would dismiss it. As for DBLCLK, it's just
unnecessary, as it should be always preceded by a DOWN message anyhow.
- Don't dismiss the popup if the message is sent to it or one of its
children, as in this case the popup itself is supposed to deal with it
(as wxComboCtrl popup does) and we don't want to prevent it from doing
it.
With these changes both wxComboCtrl and wxTipWindow seem to work as
expected.
Closes#18844.
Reimplement the logic of 16a02e6338 (Use DPI independent text size in
wxSVGFileDC, 2019-08-06) without using GetContentScaleFactor(), but
using wxDC::GetPPI() directly and do it under the platforms not using
logical pixels only.
This makes the units correct again in SVGs produced when using high DPI
under MSW even although wxDC::GetContentScaleFactor() now returns 1 in
this case.
Enable and fix keys processing in wxSymbolListCtrl::OnKeyDown().
Also set focus to this control initially as it's more useful and it's
expected that cursor arrows can be used to move the selection in it
rather than changing selection in the font comboboxes.
Note that "Enter" key still doesn't work correctly, i.e. doesn't close
the dialog when it's pressed in the symbols list control.
Closes#16033.
Co-authored-by: Igor Korot <ikorot01@gmail.com>
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
