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 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.
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.
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.
The field is used for common placement and sizing logic in
notebook-like controls that have a "controller buddy" control. Its use
isn't wxControl-specific and only relies on wxWindow API, so the
restriction to wxControl-inherited types is arbitrary.
Change the type to the more general wxWindow* pointer.
In practical terms, this allows derived classes to use e.g.
wxNativeWindow as the controller buddy.
This allows to retrieve the current contents of the text entry part of
wxSpinCtrl.
For now provide a stub in the base class, will be made pure virtual
later.
Co-Authored-By: Vadim Zeitlin <vadim@wxwidgets.org>
Introduced in 53bd139, wxReadlink() trivially wraps readlink(), but
returned int instead of ssize_t as defined for readlink() by POSIX.
Fixes "Implicit conversion loses integer precision: 'ssize_t' (aka
'long') to 'int'" on platforms with sizeof(ssize_t)>sizeof(int).
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.
Use the same name as in the other ports for the function doing the same
thing, there doesn't seem to be any good reason to name it differently.
Also avoid declaring it when wxUSE_IMAGE==0 as it's not defined in this
case (again, consistently with the other ports).
wxGTK already did it like this, but also only declared ctor not taking
wxImage in this case, while wxMSW and wxMac declared this ctor in any
case, even when wxUSE_IMAGE==0, but didn't define it then.
This doesn't matter much anyhow, as the build with wxUSE_IMAGE==0 is
clearly broken and these changes are not enough to fix it, but be at
least somewhat consistent and:
1. Don't declare methods using a class which is not available at all.
2. Do define methods using wxImage only internally, even if they do
nothing when it's not available.
No real changes.
wxWidgetCocoaImpl injects implementation of several
NSDraggingDestination protocol methods, but never called their base
implementations, presumably on the assumption that drag and drop is
explicitly supported and not builtin into native NSView-derived
controls.
This prevented native builtin d'n'd in e.g. NSTextView (text can be
copied and inserted by dragging it to the insertion point) from
working. Fixed by always calling base implementation.
Closes https://github.com/wxWidgets/wxWidgets/pull/2320
This fixes a problem similar to that fixed in the previous commit but
for SetMinSize(), which was also ignored if done after calling
wxSizer::Fit() and before showing the window, as the explicitly set min
size was also overwritten by the pending min size computed from the
client size corresponding to the sizer fitting size.
The fix is similar too: just invalidate the pending minimum size if
SetMinSize() is called.
Add wxWindow::WXSetInitialFittingClientSize() instead of handling wxGTK
TLWs specially in the common wxSizer code and override it in wxGTK to
remember that we need to reset the client size once the window is shown.
This commit shouldn't result in any changes in the observed behaviour.
Just extract the code generating wxEVT_SHOW for TLWs in wxGTK in its own
function before modifying it to avoid having to do it in two places.
No real changes, this is a pure refactoring.
We can use BCM_GETIDEALSIZE message to get the size of the button that
best fits its text and image (if present).
It gives better results for text wxButton with wxBU_EXACTFIT style.
This shortcut is undocumented, but works in rich edit controls and even
in plain ones if they use SHAutoComplete(), so support it in all
controls because this is what people expect.
Implementation is a hack, using a magic pointer value because just
storing this in wxTextAutoCompleteData is not simple, as any flag added
to it would need to be reset in several different places.
This is not used yet, but will be in the upcoming commits.
The new function has more clear semantics than GetOrCreateCompleter()
which both returned the completer value and set m_autoCompleteData to it
as a side effect. MSWEnsureHasAutoCompleteData() still does the latter,
but returns just a boolean indicating whether it succeeded or failed,
making using it more straightforward.
No real changes.
