Move this function, and the associated constant, to common code.
This required moving wxSpinCtrlDouble::Create() implementation to the
source file, but there are no real changes.
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.
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.
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>
Emulate a 1-pixel pen width as closely as possible.
This reverts:
334cf1cc91 (Take HiDPI scale into account for wxGCDC 0-width pen, 2021-04-03)
0d80050057 (Make wxGCDC behavior with 0-width wxPen consistent with MSW wxDC, 2021-03-02)
See #19077, #19115
This trivial function just allows to avoid checking if wxTheApp is not
null before calling GetTopWindow() on it.
Replace the existing "wxTheApp && wxTheApp->GetTopWindow()" calls with
wxApp::GetMainTopWindow().
No real changes.
After the previous commit the coords stored by wxGridCellWithAttr have
become redundant as the coords are now also stored as part of the key
used for an attributes map. With then only an attribute remaining in
wxGridCellWithAttr it can be removed completely, letting the value of
an attributes map point directly to a (ref-counted) attribute instead.
If source wxImage has a mask we need to create ARGB32 Cairo surface (even
for RGB image) and based on the mask values set the alpha values to fully
transparent or retain original values.
Deal with possible size changes of a multicell (both main and inside
cells) when inserting or deleting rows or columns and, in the case of
deletion only, the disappearing of a multicell's main cell.
Closes#4238.
They didn't reset the existing selection when used without Shift and
didn't extend the selection when used with Shift.
Fix both of these problems by reusing the existing logic from
GoToRelativeRow() and, added in this commit, GoToRow() which was
extracted from GoToRelativeRow().
Closes#19068.
This is not an event handler itself, so it shouldn't use "On" prefix
which is reserved, by convention, for the event handlers.
It also doesn't need wxKeyEvent, but just wxKeyboardState, so change its
signature accordingly. This will notably allow to use it from mouse
event handlers too if necessary.
No real changes.
When inserting more than one item into wxSelectionStore in the
default-selected state, the state of all the items bug the first one was
wrongly set to "selected" initially.
Just fix the typo in the AddAt() call, which was passed a wrong
variable, to fix this.
Closes#19040.
Grid cells are considered for redrawing solely based on having
a (text) value. This can lead to infinite recursion with overflowing
inside cells if wxGridCellStringRenderer::Draw() wants to draw cells
appearing after this one but instead visits the same cell again (because
of a negative cell size as opposed to expected default cell size of 1x1
or a larger spanning size) and calls DrawCell() again for this cell
which will call the renderer's Draw() again etc...
Fix by not taking inside cells into consideration for redrawing. This
is the right thing to do as earlier on in the same function a cell is
not drawn for the same reason. Also the aforementioned Draw() mentions
it shouldn't be called for cell sizes <= 0.
Also fixes the crashing grid test just introduced in 6d3dbc3fe5.
Use more appropriate colours for the row/column cell headers and don't
hardcode black (i.e. at least use white instead in dark mode) for the
frozen border.
Closes https://github.com/wxWidgets/wxWidgets/pull/2026
See #18941.
Sizing the images stored in the list should stick to the convention
adopted in the native wxImageList implemented in wxMSW.
Images stored in the list should have the sizes as it is declared for
the list even if provided bitmaps have different sizes.
In case of discrepancies their dimensions should be adjusted accordingly
(cropped or extended).
Revert 8535cde836 (Remove apparently unnecessary m_hasExplicitFont,
2020-07-14) and make 9cd3ab5ebd (Improve wxGenericTreeCtrl colours/fonts
updating on theme change, 2020-07-14) really work as expected by using
not only m_hasExplicitFont, but also m_hasExplicit{Fg,Bg}Col in order to
ensure that we only update the attributes if they hadn't been explicitly
set.
This is necessary because the hack with reusing m_has{Fg,Bg}Col didn't
work under Mac where the colour wasn't used at all when they were false.
This still seems to be a problem as the behaviour is different from that
of the other ports, but fixing this in wxOSX doesn't seem to be simple,
so don't rely on this working and use separate variables instead.
Closes#18940.
