The instantiation of the global static mapping table may happen before
the instantiation of the wxArtIds, i.e. the copy-constructor would
access not yet valid wxArtId/wxString instances.
Delay the instantiation until the first call to wxArtIDToStock call.
This is still not 100% safe, as wxArtIDToStock may be called by a
constructor of a static instance, but hopefully nobody does that.
The pre-3.1.4 definitions of the constants were just string literals,
while the type were wxString typedefs. To avoid implicit conversion
these were converted to actual wxStrings.
While the interface now matched the implementation, this has several
drawbacks:
- every use of the "constant" now is a string construction at runtime
- the constant now is an rvalue, i.e. it is impossible to take its
address.
The latter breaks its use from wxPython.
The IDs are moved to a separate file which can be included multiple
times, once from the header to have the declarations in place, and once
to instantiate the wxStrings. Using a common file avoids the declaration
and definition going out of sync.
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
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.
The constants for wxFILE_EXISTS_FIFO and wxFILE_EXISTS_SOCKET were
wrongly defined, mixing up their decimal and hexadecimal values,
resulting in wxFILE_EXISTS_FIFO & wxFILE_EXISTS_DIR being wrongly non
zero.
Fix this by redefining these bit masks correctly to avoid overlapping
the other values.
Closes#18846.
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.
Do it for consistency with the 32-bit package and to ensure that the
provided wxrc.exe binary can be run without downloading any extra files.
Closes https://github.com/wxWidgets/wxWidgets/pull/1991
