Extend the existing use of wxIcon in wxDataViewIconText,
wxDataViewCheckIconText, the corresponding renderers and
wxDataViewTreeCtrl to wxBitmapBundle.
As with the other classes, the existing setters have been preserved as
they remain almost entirely compatible with the existing code and the
return type of the existing getters was preserved, with new getters
being introduced for returning wxBitmapBundle only where they're really
required.
Update the sample to use wxBitmapBundle with its wxDataViewTreeCtrl.
Use FromDIP() to ensure that it is not too small when using DPI scaling.
Also make the code slightly more clear by using a meaningful variable
name instead of a (duplicated) comment.
Some of them had been already updated to return the values scaled
appropriately for the current DPI in 56fab0aabb (Improve wxDataView on
DPI change, 2019-01-10), but not all, so add the missing calls to
wxDataView{Progress,IconText}Renderer too.
So base classes will process the event too.
This is need for (at least) wxGenericColourButton It has its own handler,
but also needs to handle the DPI event in wxButtonImageData.
The selected state is always set for the background of a selected cell,
so it should also be set for the text/foreground. Fixes text color for
unfocused selected cells with Windows high-contrast themes.
This function must return a composite data object and not just any
wxDataObject because its callers cast the returned object to this class,
so make it a bit more type-safe.
Also rename EnableDropTarget() to EnableDropTargets(), as calling
EnableDropTarget(wxDF_XXX) would be ambiguous due to the existence of a
non-explicit wxVector ctor taking size_t (which is a mistake on its own,
but is probably not worth changing any more).
Allow specifying multiple formats to be accepted when dragging data to
wxDataViewCtrl in the generic and Cocoa implementations.
Add wxDataViewCtrlBase::EnableDropTarget() overload taking an array of
wxDataFormats to support this at the API level.
Add new DoEnableDropTarget() used by both EnableDropTarget() overloads
and implement it in the generic and Cocoa ports. GTK implementation
still uses only a single format, as before.
Also refactor the Cocoa implementation: all operations using dragged
data are now handled by wxDropTarget and unnecessary DataViewPboardType
as removed.
Update the dataview sample to show the new functionality.
In particular, don't draw them, as this would reuse the value of the
previously drawn item, which would be wrong -- just leave them blank if
PrepareForItem() returned false, which happens if GetValue() returned a
null value or a value of a wrong type.
This is more concise and less error-prone than multiplying/dividing DPI
values manually.
No real changes except, maybe, in wxSlider code where the rounding was
done differently before for some reason.
This makes several methods that didn't have any effect before work
correctly, including SetToolTip(), whose effect is now shown in the
sample, but also SetCursor() and SetLayoutDirection().
Some methods would now actually work too well: SetForegroundColour() and
SetBackgroundColour() implementations in wxCompositeWindow apply to all
sub-windows, but in wxDataViewCtrl they are only supposed to affect the
items, but not the header, so we need to override them to prevent the
base class version from being used. It is still preferable to explicitly
disable these two methods and inherit all the other ones (including any
possibly added in the future) from wxCompositeWindow to implementing all
the methods manually in wxDataViewCtrl itself.
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 an item is marked as not containing any value in the expander
column, we must still draw the expander button if it has children, so
skip only drawing the item value in this case (and also preparing it for
drawing it, as calling PrepareForItem() would trigger an assert failure
for the items without value), but still execute the rest of the drawing
code for it, including drawing the background and expander button.
Closes https://github.com/wxWidgets/wxWidgets/pull/2144
We can't skip resorting wxDataViewCtrl contents when the sort order is
defined by the model class, as it can change at any moment, so restrict
this optimization to the cases when we're sorting by the value of some
column.
Closes https://github.com/wxWidgets/wxWidgets/pull/2153
Do not invoke a renderer's PrepareForItem when estimating best column
width in generic wxDVC for items with no value because PrepareForItem
fails for items with no value when the null variant cannot be converted
to the expected type.
Closes https://github.com/wxWidgets/wxWidgets/pull/2149
Add the usual handlers for '-', '+' and '*' keys. The last one is
especially convenient, as it does something that couldn't be easily done
at all interactively before.
This convenient method allows to expand all children of the item
recursively.
This is directly supported by both native implementations, so it makes
sense to have this in wxDataViewCtrl itself, even if it could be also
(less efficiently) implemented in the user code.
This reverts the changes of 4dc78a33e0 (Fix adding items to a never
opened branch of generic wxDataViewCtrl, 2018-01-17) which was supposed
to fix a problem which doesn't seem to be reproducible any longer (and,
unfortunately, wasn't recorded in the commit message back then), but
introduced another problem instead: postponing adding the node to the
tree didn't work correctly in case of depth-first model traversal in the
user code calling ItemAdded() for all the items, as in this case the
next call to ItemAdded() for a child of the item that wasn't added to
the tree because its parent hadn't been opened yet, would result in
adding this item and all its siblings to the tree when FindNode(parent)
would be called. And this, in turn, would result in the siblings of this
item being added to the tree twice.
Adding a test reproducing this problem is difficult, as we don't have
any way to check the internal state of wxDataViewMainWindow from the
outside, so this commit still doesn't do this, unfortunately.
Closes#18405.
GetItemByRow() returned a valid row even for an item which was collapsed
which is clearly inappropriate for its use in GetItemRect(), which is
supposed return an invalid rectangle if the item is not visible. It also
might be inappropriate in other cases, but this is not totally clear and
it seems like it is supposed to return a valid row even for collapsed
items at least sometimes, so just make its behaviour conditional by
adding a new flags parameter to GetItemRect() and to Walker() helper
used by it itself, so that it could skip over collapsed items.
Update the test to show that it succeeds now even when the item is
present in the tree, as it only passed before because the item had never
been expanded at all, and so wasn't really present in the tree
structure and the updated test would have failed without the changes to
the code in this commit.
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 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
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.
