Every time spin control precision, minimal or maximal value changes there
is necessary to adjust numeric box size to the new dimension of displayed
number.
See #18734.
For native wxGTK implementation default spin control precision is derived
from the precision of the increment value. Fot the sake of consistency the
same should be done in the generic implementation.
Closes#18764.
Define it in wx/defs.h directly instead of conditionally including
wx/windowid.h from there just in order to get this type definition.
This has several advantages:
- wxWindowIDRef is not defined in (maybe) non-GUI code including
wx/defs.h, as it should be the case for this class defined in
core library only.
- wx/windowid.h becomes a normal header, including wx/defs.h as
(almost) all the other ones instead of being exceptional.
- wx/windowid.h doesn't need to be included by wx/utils.h at all
just to get wxWindowID definition.
Closes https://github.com/wxWidgets/wxWidgets/pull/1850
Add wxXSync class which adds delays between the synthesized events
sufficient for them to be processed by the higher layers (X, GTK).
This makes it possible to run the UI tests by default with wxGTK.
Closes https://github.com/wxWidgets/wxWidgets/pull/1845
This never worked correctly as using operator<<() with wchar_t pointer
just fell back to the overload for void pointers, i.e. printed out the
address of the wide string, which wasn't especially useful, but with
C++20 it doesn't even compile, as this overload is explicitly deleted.
Fix both problems at once by actually doing something useful for it
instead and printing out data in either current encoding or UTF-8 if
converting it to the current encoding failed.
When determining the entry width in wxSpinCtrlDouble, we need to account
not only for the width of the integer part, but also for the number of
digits that determines the width of the fractional part.
Do it in the overridden version of (now virtual) GtkSetEntryWidth().
See https://github.com/wxWidgets/wxWidgets/pull/1817Closes#18734.
Using too high precision could result in bogus digits appearing in the
displayed value, e.g. 0.058 shown in percents (with a factor of 100)
appeared as 5.800000000000001 before this change.
Closes https://github.com/wxWidgets/wxWidgets/pull/1831
Enable warnings for CMake builds and fix some warnings that this
exposed.
Also add wxUSE_NATIVE_DATAVIEWCTRL option and change default GTK version
to 3 for CMake too.
See https://github.com/wxWidgets/wxWidgets/pull/1825
It's not enough to set the parent pointer in the child, the parent also
needs to be aware of its child, so call AddChild() to do both at once.
This ensures that find dialog with non-null parent is destroyed by it
when it is itself destroyed.
Closes#18747.
Update the code doing hit testing to use FromDIP() too, to be consistent
with the changes of 3a9b5001ce (Fix size of wxGenericTreeCtrl buttons
when using high DPI, 2020-02-23) # Please enter the commit message for
your changes. Lines starting.
See #18674.
Closes#18749.
It always returned wxDragNone since the changes of f5548e399e (Fix
problem with dragged icon remaining on screen under MSW 10, 2020-01-11)
which wrongly changed pdwEffect to DROPEFFECT_NONE before doing anything
else, disregarding the fact that it's an in-out parameter and not just
an output one.
Fix this by simply not doing this, just as it hadn't been done before.
See #18499.
gcc complained about converting NULL to long (-Wconversion-null), so use
0 explicitly. Also really pass the pointer to the first element, rather
than iterator, which is not guaranteed to be a pointer.
This amends the changes of d1553c63ed (Improve support for TABs in
wxListBox under MSW, 2020-04-13).
See https://github.com/wxWidgets/wxWidgets/pull/1789
It's not useful to allow dragging from the control area where there are
no items and it resulted in assert failures due to using an invalid row
in wxDataViewDropSource::GiveFeedback(), so simply don't do it at all.
Note that native GTK wxDataViewCtrl implementation doesn't do this
neither, so it also makes the behaviour more consistent.
Closes https://github.com/wxWidgets/wxWidgets/pull/1828
We don't have our own dlxxx() implementations under Darwin since 76c5594
(Remove our own dlxxx() functions emulation for OS X <= 10.3.,
2013-10-17).
wxHAVE_DYNLIB_ERROR is reduced to being the same HAVE_DLERROR, so use
the latter one instead.
Closes https://github.com/wxWidgets/wxWidgets/pull/1826
This is useful for read-only grids, in which an editor can't be shown to
copy the value of a cell, and also for copying an entire selection block
and not just a single cell.
Closes https://github.com/wxWidgets/wxWidgets/pull/1824Closes#13562.
Always set the LB_USETABSTOPS style flag to achieve behaviour more
compatible with other platforms and expand TABs to align them at tab
stops positioned at every 8 characters.
Also add MSW-specific MSWSetTabStops() method allowing to customize tab
stops.
Update the documentation and the sample to demonstrate using TABs.
Closes https://github.com/wxWidgets/wxWidgets/pull/1789
Previously, pressing Enter in a cell of a row which wasn't the last one,
but was the last shown one, didn't do anything because we explicitly
checked whether the cell was in the last row and not in the last visible
row, but MoveCursorDown() doesn't move the cursor for the latter, and
not just for the former.
Fix this by avoiding any row checks at all and just calling
MoveCursorDown() in any case and DisableCellEditControl() if it didn't
do anything.
Closes#18754.
Our code didn't convert 32-bit offset to (possibly 64-bit) m_Offset
correctly in the first place, and didn't check if the offset remained
valid after adjustment.
Fix both problems by using explicit cast and checking for the latter
explicitly.
Credit to OSS-Fuzz: this solves its issue 20527.
Deleting last grid rows or column in a few event handlers could result
in asserts/crashes in wxGrid code if the event handler also called
event.Skip(), as wxGrid still tried to perform the default action using
the deleted cell, when these events happened in the last row or column.
It's not totally clear whether calling event.Skip() after performing an
action modifying the grid should be allowed at all, but, in doubt, at
least avoid crashing if it does happen, by considering the event as
being handled (and even vetoed) if its handler deleted the cell in which
it was generated.
Closes#18731.
Move the logic determining the return value of SendEvent() into its own
function instead of repeating it twice.
No real changes, this is a pure refactoring.
In addition to the current methods to add/delete one item to the control
we would need a method to replace all existing control items with new ones
at once.
Calling FindFirst() with an URL without wildcards returned the correct
result, but didn't reset m_findIter, which kept its value from the
previous search that could have been invalidated since then, e.g. if
RemoveFile() has been called. Using this value could result in a crash
during the next call to FindNext().
Fix this by ensuring that we always reset m_findIter to the valid (even
if pointing to the end) value as the first thing we do in FindFirst().
Closes#18744.
This is more correct as saving the current width of the last column
would prevent the user from shrinking it under the last automatically
set size, i.e. the UI behaviour would change after restarting the
program, which shouldn't be the case.
Doing this required making WXGetManuallySetWidth(), which previously
existed in the generic version only, available in all ports, so do it
and also rename it to WXGetSpecifiedWidth() in the process, as this
seems a somewhat better name (it doesn't have to be manually specified,
i.e. it could also be done by the program itself or even implicitly by
wxPersistentDataViewCtrl).
Don't make this function public, at least for now, because it's not
clear how could it be useful and it might still need to be changed to
behave differently in the other ports.
Columns without any explicitly specified width still shouldn't be shrunk
down to 0 size by UpdateColumnSizes(), so handle them as if they were
created using wxDVC_DEFAULT_WIDTH instead -- which is what their actual
width is/would be.
This is a better fix than the one in 0c90ea40c3 (Don't auto-resize
wxDataViewCtrl columns below their initial size, 2019-10-03) and that
commit can be reverted now, as will be done soon.
See #18343.
Not doing this when the last column size should have been exactly equal
to its manually set size resulted in showing the horizontal scrollbar
unnecessarily.
Using too high precision could result in bogus digits appearing in the
displayed value, e.g. 0.058 shown in percents (with a factor of 100)
appeared as 5.800000000000001 before this change.
