Using c_str() for arguments to wxString::Printf(), Format() and
wxLogXXX() is useless since wx 2.9 days, so simply remove them.
No real changes, this is just a (long due) cleanup.
Use wxTEST_RUNNER in this test, which can be/is set to "wine" by the
GitHub wxMSW CI workflow and can also be set manually if necessary, to
make executing MSW commands under non-MSW systems have a chance to
actually work (but note that the tests still fail when run under Wine).
Allow using wxPrintf() etc with std::string_view arguments when using
C++17.
This is inefficient but still more convenient than not being able to use
string_view at all.
This is required to avoid warnings (and worse, probably) due to
conflicting function declarations in the platform SDK and Cygwin headers
that have started happening since 8dfcb582da (Regenerate configure after
enabling IPv6 support by default, 2021-06-15).
This extends the changes of e0005c1d93 (No longer include the system
headers first, 2021-04-22) to the platform-specific headers included for
Cygwin/MinGW wxMSW builds, as this shouldn't be necessary neither any
more (but doing it for wxQt is still needed, for the reasons explained
in the new comment added by this commit).
It also incidentally fixes a problem in Cygwin build since enabling IPv6
in 8dfcb582da (Regenerate configure after enabling IPv6 support by
default, 2021-06-15) as including unistd.h directly results in warnings
if wx/defs.h, which predefines __USE_W32_SOCKETS, hadn't been included
before.
This was broken in to 682cb8355c (Replace "sendEvent" parameter in
wxGridSelection with "eventType", 2020-08-21) which changed Select() to
take wxEventType argument but still passed it "true" in a few places.
Fix this and add a unit test verifying that this works as expected.
Ideal would, of course, be to avoid implicit conversions from bool to
wxEventType but making wxEventType anything other than int, for which
such conversions are unavoidable, is too backwards-incompatible to
seriously consider.
Otherwise wxDynamicCast-ing wxAuiNotebook to wxBookCtrlBase didn't work
(even if the more usual and useful upcast did still work).
Add a unit test for this.
There doesn't seem to be any reason to only forward CHAR events, but not
KEY_{DOWN,UP} ones, so do the same thing for the latter ones too.
This allows to get rid of GetMainWindow() call in wxDataViewCtrl unit
tests, as wxEVT_KEY_DOWN are now correctly received in the control
itself and not just its main window.
This undoes accidental change of ms_classInfo from public to protected
in 95c98a0b5f (Work around -Wuggest-override for event table macros from
gcc 11, 2021-04-25).
Also add a unit test checking that using wxCLASSINFO(wxObject) compiles
and works as expected.
All BCC makefiles were removed as a part of "Remove support for Borland
C++ compiler" PR; however, a few of them sneaked back as a part of the
newly introduced wxWebRequest.
Remove them for good.
Add more functions for manipulating wxImage colours.
Show using them in the same and add new unit tests for them.
This is a squashed commit of branch 'tomay3000/image-lightness'.
Closes https://github.com/wxWidgets/wxWidgets/pull/2310
Disabling -Wsuggest-override inside macros is broken in gcc, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578, and has started
affecting wxWARNING_SUPPRESS_MISSING_OVERRIDE since gcc 11, i.e. this
macro doesn't have any effect any more and the warning is still given.
Avoid it by actually specifying "override" for gcc 11 (as doing it for
all compilers would result in -Winconsistent-missing-override from
clang) and check that we don't get this warning in the allheaders test.
Also don't use wxDECLARE_ABSTRACT_CLASS() inside wxObject itself, now
that it uses "override", which is not appropriate for the base class
version. This is arguably more clear and should have been done like this
since the beginning anyhow.
Using increment greater than 1 but with a fractional part should still
work, i.e. should use enough digits to fully show the fractional part of
the numbers that can be obtained by using this increment.
wxSpinCtrlDouble::SetIncrement() should increase the number of digits if
necessary because not doing it would be inconsistent with the initial
determination of the number of digits in the ctor and would actually
lose the digits displayed, but it seems unnecessary to decrease the
number of digits and it might be surprising, so don't do it.
Add a test for this behaviour and document it.
This is consistent with using the value of the increment specified in
the ctor for setting the initial number of digits, it was surprising
that creating the control with some value of the increment (e.g. 0.1)
and calling SetIncrement(0.1) later resulted in very different outcomes,
as in the former case the value was shown with a digit after the period
while in the latter case only the integer part was shown.
This also makes the behaviour compatible with that of the previous
versions of the generic wxSpinCtrlDouble, which used "%g" to format the
number before the changes of edc553870f (Fix displaying wxSpinCtrlDouble
values with default precision, 2020-05-18), as they did show the
fractional part even in the latter case.
Add a test checking that this works as expected: before this commit, the
test failed with "1 == 1.2" and "1 == 1.23" errors.
The function was documented to not generate the events, but actually
did generate wxEVT_TEXT ones, even if it didn't generate wxEVT_SPINCTRL.
This was inconsistent with wxGTK and generic wxSpinCtrlDouble used under
MSW, so change this to avoid the unwanted events.
Previously, wxSpinCtrl (using native control) and wxSpinCtrlDouble
(using the generic implementation) behaved differently in this case,
with the former changing its value but the latter keeping the last valid
value instead.
Make them behave the same by resetting the value in both cases and
document this behaviour.
Fix the bug introduced in the recent 34ab87ce4d (Get rid of CppUnit
boilerplate in wxSpinCtrlDouble unit test, 2021-04-19) which resulted in
failures in the subsequent unit tests and ensure that the spin control
is destroyed at the end of the test.
wxSpinCtrl::GetValue() behaviour after calling SetValue("") is currently
inconsistent between wxMSW and wxGTK, or even between wxSpinCtrl and
wxSpinCtrlDouble in wxMSW.
Disable the recently added test checking it for now.
This warning flag is really only used for stdlib debugging/writing,
and is off by default so that normal users of the library don't see
any warnings generated by the library (since they have no control
over it).
Make it possible to use a string value different from the numeric value,
as wxMSW version allows this and some existing code depends on it.
Closes#19140.
This just uses the existing wxImage ctor from XPM data and wxCursor ctor
from wxImage, but will allow the code creating cursors from XPM to still
work even when wxImage ctor from XPM is made explicit.
Add a trivial test just to check that the new ctor can be used.
These paths are actually URLs and so the special URL characters must be
percent-encoded in them.
Document this and add a test checking that this is how it works.
Closes#19142.
Since f7247086c2 ("Fix storing wxBitmap data in GdkPixbuf", 2019-09-18),
919a4ec702 ("Fix drawing wxBitmap with mask", 2019-09-18) and other
commits (see #18498, #18508) RGBA wxBitmaps with masks are drawn properly
under wxGTK2 so if source wxImage has both alpha channel and a mask
the target wxBitmap also should have both components.
Since f7247086c2 ("Fix storing wxBitmap data in GdkPixbuf", 2019-09-18),
919a4ec702 ("Fix drawing wxBitmap with mask", 2019-09-18) and other
commits (see #18498, #18508) RGBA wxBitmaps with masks are drawn properly
under wxGTK2 so only wxBitmap raw RGBA data should be transferred to
wxImage RGBA data because mask is stored in the target wxImage separately.
