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
wxToolBar created with wxTB_HORIZONTAL | wxTB_BOTTOM had two issues:
(1) There was a toolbar-high gap below the menu bar.
(2) The status bar was not positioned correctly.
Fix both issues by taking into account that wxTB_TOP is an alias for wxTB_HORIZONTAL
and so a wxToolBar can have quite counter-intuitively set both wxTB_TOP and wxTB_BOTTOM.
In such cases it means that the toolbar is horizontal and on the frame bottom,
this needs to be accounted for when computing the origin of the frame client
area as well as the status bar position.
Closes#18760
This is not a good idea because we really don't want them to wrap around
and it also provokes signed/unsigned comparison warnings when using
them.
Also make this variable and the other related one const.
Set the proposed drop index in wxEVT_DATAVIEW_ITEM_DROP_POSSIBLE event
generated by the control to allow dropping either on or between the
items in the control, as it was already possible with the Mac version.
Closes https://github.com/wxWidgets/wxWidgets/pull/1822
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.
Upgrade the submodule to a version which doesn't try to use SSE2 with
this old compiler, as it doesn't support the required intrinsics.
See https://github.com/wxWidgets/libpng/pull/4
