This method is implemented in the generic version used under the other
platforms as well, but was documented as being MSW-only in 89bb3f0244
(interface revisions, 2008-10-17) for some reason.
Just remove the note added by that commit.
Instead of using dynamically created brushes (implicitly from stock colours)
we should use corresponding stock brushes because once created they are
stored in the cache what can slightly improve performance.
wxUSE_UNICODE_UTF8 is not default anywhere since a long time.
Also mention that wxUSE_UNICODE==0 build is already deprecated and will
be dropped in the future.
Add a build option (--disable-pic, wxBUILD_PIC=OFF) to disable it.
Note that it is always enabled for shared libraries and static third party libraries.
This was disabled, but only didn't work because wxSlider used tiny size
in wxGTK by default previously. After correcting this in aa2d159e8c (Use
more reasonable length for wxSlider in wxGTK by default, 2020-08-04),
the unit test passes with wxGTK too and can be reenabled.
Closes https://github.com/wxWidgets/wxWidgets/pull/1992
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
Requires updates of expat and tiff submodules.
Most libraries have their own CMakeLists, add a comment with a suggestion to
use this for implementing build-in support.
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.
