The current, but not selected, item was not visually marked in any way
since the changes of 4ac0250f90 which
replaced the calls to wxRendererNative::DrawFocusRect() with the calls
to DrawItemSelectionRect() which is not called when the item is not
selected.
Restore DrawFocusRect() call in this case and also pass
wxCONTROL_FOCUSED to DrawItemSelectionRect() even though this doesn't
seem to change much in practice.
Closes https://github.com/wxWidgets/wxWidgets/pull/1089Closes#18304.
After 841c14c37c, reducing width of a
generic wxDataViewCtrl caused flickering (horizontal scrollbar
appearing and disappearing immediately) when the columns were resized
by user code to fix exactly.
Fixed by calling AdjustScrollbars() after determining column sizes. It
doesn’t make sense to call it before, because UpdateColumnSizes() may
change required width.
See #18295.
As wxDataViewColumnList was never public, it should be fine to not
define it any more and use a vector instead.
This makes the code more clear and also marginally more efficient.
Previously, the last column couldn't be effectively resized at all, as
its size was always automatically set to the remaining width of the
window after subtracting the widths of all the previous columns. Now
this is only done if this remaining width is greater than the width
given to the column by the user or by the program.
Effectively, this means that the user can now drag-resize the column to
increase its size (at the price of showing the horizontal scrollbar).
See #18295.
This reverts commit 24054c95d8 as it
actually should be possible to increase the size of the last column,
even if this shows the horizontal scroll bar.
The code added in 4156e1a5c9 didn't quite
work correctly because it used the old size of the window, before it was
resized, and not the new size. This was almost unnoticeable when
drag-resizing the window, but very noticeable when maximizing the
containing TLW, as could be seen on the 3rd page of the dataview sample,
for example, where the last column kept its size instead of expanding.
See #13904, #18295.
Previously, the editor was hidden if the left mouse button was pressed,
but not for the right (or any other) button, which could result in a
confusing situation when a user could select a command from a context
menu shown from the corresponding event handler and start editing
another item while the current one was still being edited too.
This was already the case if the item was not visible because its parent
was not expanded, but now make it also true for the items which are not
visible due to the current scrollbar position.
Add unit tests checking for this and also verifying that GetItemRect()
returns the coordinates in the physical window coordinates.
Rename its m_ret field to a more clear and more consistent with
RowToTreeNodeJob::m_current name and also make m_current, unlike m_ret,
0-based from the beginning instead of having to subtract 1 from it in
GetResult().
There should be no changes in the class behaviour.
Get rid of hardcoded, without any explanation, "-2" value passed to this
class ctor and instead initialize its m_current member to -1 and explain
why do we do it and increment it after processing the current item, not
before, in operator().
No changes in behaviour.
Calling GetItemRect() for an item which was not currently visible
because its parent was collapsed resulted in silently returning the
value for a wrong value before the recent fix to GetRowByItem() and in
a crash after it because GetTreeNodeByRow() returned null when passed
invalid row index.
Fix this by explicitly checking whether the item is shown and just
returning an empty rectangle instead.
Also document this behaviour and add a unit test for it.
If the item was not found at all, which can happen if all its parents
are not expanded, this function still returned a valid but completely
wrong row index.
This affected many functions which could call it for the items which
were not necessarily visible, i.e. all of them except for the event
handlers as events can only affect the visible items, including but not
limited to SetCurrentItem(), all the selection-related functions, all
the expansion-related functions, EnsureVisible(), HitTest() and
GetItemRect().
It doesn't make much sense to use an "unsigned int" variable only to
cast it to int everywhere where it's used. Just make it "int" from the
get go and have a single cast to int in the caller.
Also make m_row const as it never changes.
RefreshRow() is called very frequently, and in particular after every
ItemChanged notification. Calling GetEndOfLastCol() in it repeatedly is
extremely inefficient in presence of auto-sizing columns, and doesn't
make much sense anyway - controls with significant space unoccupied by
columns are rare, and rendering of such unused space is efficient (just
background erase). It is therefore more performant to simply refresh
the entire row instead of repeatedly and expensively calculating the
smallest rectangle that needs repainting.
Fixes previously wrong calculation of the refreshed rectangle in
RefreshRows() in the process.
Fixes major performance regression introduced in
77c7c80696.
Closes https://github.com/wxWidgets/wxWidgets/pull/970
This allows showing radio buttons in wxDataViewCtrl easily and natively.
Notice that this approach, adding an extra function to the existing
renderer class instead of creating some new wxDataViewRadioRenderer (see
https://github.com/wxWidgets/wxWidgets/pull/809), was finally chosen
because it is simpler to implement and, more importantly, because it
will be more natural to generalize if/when we also add a 3-state
check/radio renderer.
Closes https://github.com/wxWidgets/wxWidgets/pull/853
Simply translate wxEVT_HEADER_END_REORDER into this event, which was
previously only sent by the macOS version.
GtkTreeView doesn't seem to support column drag-and-drop at all, so this
event is still never generated by wxGTK.
Closes#14297.
Previously this method was only available in the generic wxDataViewCtrl,
move it to the base class to make it possible calling it in portable
code and document it.
Closes#14617.
This used to work in 3.0, but got broken with the switch to using a
native function for rendering the gauge in generic wxDataViewCtrl
86cf756ba9 (see #16406).
Restore it now, even if it requires not one, but two hacks: one at
wxRendererGeneric level to guess whether a custom colour is being used
or not by examining wxDC::GetBackground(), and the other one in
wxDataViewProgressRenderer itself to fall back to wxRendererGeneric if
the colour is specified. But it is arguably worth doing this to fix the
regression, even if it would be nice to provide a better API instead
(see #18076).
Closes#17885.
For consistency with wxListCtrl under MSW (which is the only platform
where this change has any effect, as wxHD_BITMAP_ON_RIGHT is only
supported there), put the column images on the right side in
wxDataViewCtrl too.
Closes#13350.
The buttons were truncated, making them look ugly, because we didn't
allocate enough space for them. Instead of complicating generic
wxDataViewCtrl code even further with more MSW-specific code, just let
DrawItemTreeButton() center the expander itself in the space allocated
for it.
This still involves guessing the width of the expander, but this doesn't
need to be done as precisely, so it's still an advantage. Note that
previously calculating expander size involved m_lineHeight, for some
reason, but now we use GetCharWidth() for it, which is more appropriate.
Closes#17863.
No event was sent if the selection was narrowed by clicking on an
already selected item without any key modifiers pressed.
Fix this by generating an event always on click and not only when
selecting a new item.
Closes#17881.
Recent sorting-related changes resulted in calling FindNode(), which
can only be used with the non-"virtual list" models, unconditionally,
after the items values was changed by user, resulting in a crash.
Add the missing IsVirtualList() check and also add a comment explicitly
stating that all code involving wxDataViewTreeNode can only be used
after checking that IsVirtualList() returns false.
Closes#18057.
The comparator used with std::sort() must return true only if the first
item is strictly less than the second one, this is a requirement of the
sorting algorithm and not respecting it results in wrong final order.
See https://github.com/wxWidgets/wxWidgets/pull/642
Checking that a pointer is non-null before dereferencing it is perfectly
useless: the code will crash anyhow, so assert doesn't help with
debugging it in debug builds nor with preventing the crash in release.
SetHasChildren(true) must be called before checking GetChildNodes() if
the parent hadn't had any items in the initial model.
Also remove the assert checking that the node is open in
BuildTreeHelper() as we may need to build even a closed tree branch.
Calling ItemAdded() on a parent item that had never been opened yet
"lost" all its children that initially existed in the model, as the
corresponding subtree wasn't built any more in Expand() when this item
was finally opened because the list of item children wasn't empty any
more after ItemAdded() added the new child to it.
Fix this by simply not doing anything in ItemAdded() in this situation,
there is no need to update a closed tree branch immediately anyhow.
