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.
Recent optimizations avoiding resort on item change (see
https://github.com/wxWidgets/wxWidgets/pull/642) have also optimized
away refreshing the modified item, which was done implicitly, as a side
effect of resorting, before, so the changes were not reflected on
display immediately any longer.
Fix this by simply refreshing the item explicitly and also add a way to
test for the correct behaviour in the sample.
No real changes, just add the new DoItemChanged() used from both
ItemChanged() and ValueChanged() notifications to avoid repeating the
same code in both functions.
This is a micro-optimization, as pre-increment is at least as efficient
as post-increment and typically slightly more so because it doesn't need
to make a copy of the iterator, and better conforms to the prevailing
C++ style.
Closes https://github.com/wxWidgets/wxWidgets/pull/655
This didn't make any sense, all these objects reachable from the given
root node are used by the same window, so storing the same pointer in
all of them just wasted memory unnecessarily.
Avoid this by passing wxDataViewMainWindow pointer explicitly to those
methods of wxDataViewTreeNode that need it.
No changes in behaviour, this is just a (memory use) optimization.
Test whether this is the first child before testing whether the branch
is open as this allows to avoid the special case of inserting the first
child under the root node and simplifies the assert condition to a
simple check that the sort order is already what we expect.
Having to set up global variables before (re)sorting the items was too
ugly and became even more so after the latest changes optimizing item
sorting as sorting is done in more places now.
Improve the code by introducing a SortOrder class instead of dealing
with the sort column and sort order direction separately and,
especially, by using std::sort() (which should be fine to use here,
considering that it's used since quite some time in wxArrayString
implementation) with a comparator object instead of qsort(), which
doesn't allow passing any data to the sort callback otherwise than via
the global variables.
No changes in behaviour.
Simplify some code and make it more clear, notably by changing
conditionals to be easier to follow.
Also avoid repeating the same functions calls (like SortPrepare() or
UpdateDisplay()) by folding them into the functions that actually need
them to be done.
By simply putting two bool fields consecutively to each other, we reduce
the number of bytes of padding used from 6 to 2 in a typical 32 bit
build, saving 4 (or 8, in 64 bits) bytes per branch item.
Declare the variables just before using them (and also initialize them
at the same time); use more readable variable names; fix braces style
and add a comment explaining why do we do all this in the first place.
No real changes.
SetSelections was clearing the previous selection, invalidating the
current item, but didn't set it after selecting the new items.
This was causing issues in keyboard selection, e.g. pressing Shift+click
didn't select all the items between the selected and the clicked ones.
Fix this by making the last item of the new selection current, which is
the expected behaviour considering that SetSelections() should be
equivalent to calling SetSelection() with all items one by one.
Signed-off-by: Anil Kumar <anilkumar8753@gmail.com>
Closes https://github.com/wxWidgets/wxWidgets/pull/557
wxRect to draw the background was prepared in a wrong way if wxDataView had
vertical or horizontal rules.
Fix this by adjusting the correct component of the rectangle when using
horizontal rules and by fixing an off by one bug when using vertical ones.
Handle "&" in exactly the same way as "&" in wxMarkupParser, i.e. do not
map the former to "&&" to prevent it from being interpreted as a mnemonic as
this is incompatible with using markup for anything but the control labels,
e.g. for wxDataViewCtrl items text, in which mnemonics are not recognized.
And even when using markup for control labels, it was a questionable decision
as it's really not clear at all why should the XML entity and the raw
character itself be handled differently.
Also split wxMarkupText into two classes, wxMarkupText that handles
mnemonics in the markup (which is typically a label) and a very
similar, but not derived, wxItemMarkupText that handles mnemonics-less
markup for list etc. items, uses DrawItemText() and supports
ellipsizing.
Illustrate the use of ampersands in the dataview sample.
