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.
Make this part of SetDigits() reusable in order to be able to also use
it in DetermineDigits() now and in SetIncrement() in the upcoming
commit.
No real changes yet.
It doesn't seem right to leave it unchanged when increment is outside of
[0, 1] interval, we should still set it to something in this case.
And doing this makes it unnecessary and redundant to initialize m_format
in Init(), as it will be always done when DetermineDigits() is called
from Create() anyhow.
Ctor of a template class specialization shouldn't actually repeat the
specialized template arguments, as it was done in 65cbf40b7e (Add
wxNO_UNSAFE_WXSTRING_CONV2 macro, 2019-10-21), so remove them because
this doesn't compile with g++ 11, even though it (wrongly?) did with the
previous gcc versions.
Arithmetic operations on the elements of different enums are deprecated
in C++20 and the latest compiler versions warn about them.
While individual warnings could be fixed in wxWidgets itself (although
it would be quite an effort to do it for all ~500 of them), it wouldn't
help with the same warnings in the applications using wx, so prefer to
do it by explicitly defining the operations on the enums that can be
combined with each other by using wxALLOW_COMBINING_ENUMS() macro,
except for a single warning in wxTar code where it's easier to just not
use an anum at all.
C++20 deprecates arithmetic operations with the elements of different
enums and at least clang 10 and MSVS 2019 already warn about this when
compiling in C++20 mode, so avoid such operations at least in the public
headers to avoid warnings in the applications using wxWidgets and C++20.
In addition to linking with Winsock 2, also use winsock2.h.
This allows to turn on IPv6 support on by default under MSW, so turn it
on under Unix too for consistency.
Predefine _WINSOCK_DEPRECATED_NO_WARNINGS to avoid warnings about
deprecated (but still available and very unlikely to be ever removed)
Winsock 1 functions that we still use.
This fixes regression introduced in de10f054c4 (Improve calculating
wxButton best size under wxMSW, 2021-04-08) which didn't check whether
BCM_GETIDEALSIZE succeeded -- as we must do, because in some situations
(when using very old systems or not using a manifest even under newer
ones), it does indeed fail.
Headers wx/filehistory.h and wx/filename.h were included only
when WX_PRECOMP was not defined.
However, these two files are not included in wx/wxprec.h,
so they must be always included directly.
Closes https://github.com/wxWidgets/wxWidgets/pull/2344
This requires manually sending the original key event back to the native
control because NSOutlineView doesn't implement the NSTextInputClient
protocol and so doesn't allow handling the keys in the usual way.
This partially undoes the recent changes to wxGTK wxSpinCtrl and reverts
to the previous behaviour, which was actually compatible with wxMSW, and
returns the minimum value when the text of the control is set to an
invalid string.
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.
We didn't document using wxwin.m4 at all anywhere, so do it at least
minimally now (we still need a separate page documenting its full
functionality) and also show a simple makefile using wx-config.
Closes https://github.com/wxWidgets/wxWidgets/pull/2338
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).
Fixes this warning:
In file included from ../../include/wx/html/helpctrl.h:19,
from ../../include/wx/help.h:27,
from ../../include/wx/cshelp.h:18,
from ../../tests/allheaders.h:85,
from ../../tests/allheaders.cpp:435:
../../include/wx/html/helpfrm.h:74:50: error: declaration of 'wxWindowID' shadows a global declaration [-Werror=shadow]
74 | wxHtmlHelpFrame(wxWindow* parent, wxWindowID wxWindowID,
| ~~~~~~~~~~~^~~~~~~~~~
In file included from ../../include/wx/wxprec.h:12,
from ../../tests/testprec.h:4,
from ../../tests/allheaders.cpp:433:
../../include/wx/defs.h:1965:13: note: shadowed declaration is here
1965 | typedef int wxWindowID;
| ^~~~~~~~~~
See https://trac.wxwidgets.org/ticket/19153
The entered text wasn't taken into account, as the override was still
used when its numeric value was retrieved by GtkSpinButton using our
"input" handler, so reset the override now as soon as we get "changed"
signal.
This doesn't seem to change anything in practice, but still use the
correct return type.
Co-Authored-By: Paul Cornett <paulcor@users.noreply.github.com>
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.
No real changes yet, just refactor the code to always connect these
signals handlers and not just when using non-decimal base.
Add wxSpinCtrl::GTKInput() and GTKOutput() virtual methods to handle
these signals appropriately depending on the type of the control.
This will allow further customizing conversion to/from string in the
upcoming commit and will also make it possible to handle UI locale
different from the C locale in the future.
Just use this function now that it's available rather than calling
gtk_entry_get_text() (and sometimes forgetting to specify UTF-8 encoding
explicitly).
