This implementation suffers at least from 2 problems:
1. It doesn't support icons at all.
2. It toggles the checkbox when clicking on the text and not just on the
checkbox itself, as would be expected.
but it's still better than the current version which simply doesn't work
at all, i.e. can't be toggled in any way (and also doesn't draw itself
correctly when using dark mode under macOS 10.14+), so use it for now.
A better solution would be to fix the problem with ActivateCell() not
working at all (see #17746) and update the code to respect drawing in
dark mode.
Closes#17473.
Closes https://github.com/wxWidgets/wxWidgets/pull/904
The icon wasn't updated when the node was expanded (or collapsed) due to
the inversed check for HasImageList().
Fix this by correcting the check.
Closes https://github.com/wxWidgets/wxWidgets/pull/929
Implement support for this attribute only in the generic version so far,
it will hopefully be implemented for the natives ones in the future.
Also add a new toggle column to the dataview sample to check how it
works: checking the items in this column enables using this attribute
for some other ones.
Closes#18180.
Wrong pointer was used to initialize wxDataViewItem (apparently since
always, i.e. this function could never have been used successfully...).
Closes#18132.
Vectors passed to wxDataViewListCtrl::{Append,Insert,Prepend}Item()
functions must have the correct, i.e. equal to the column count, number
of items as otherwise accessing them later would result in a crash.
Add checks verifying that this is indeed the case.
Closes https://github.com/wxWidgets/wxWidgets/pull/724
Previously this event was not sent for the standard renderers, such as
wxDataViewTextRenderer, at all in wxGTK because the base class
FinishEditing() class didn't do anything if m_editorCtrl was null, as it
was always the case for non-custom renderers.
Fix this by refactoring the base class code in yet another way and
extracting the part which can be reused by both the generic and GTK
implementation in a new DoHandleEditingDone() function and call it from
wxGTK code.
Finally, check "editing-canceled" property to also correctly generate
the event with IsEditCancelled() returning true when editing is canceled
by e.g. pressing Esc in a standard renderer too.
And, as a final bonus, this makes the (just introduced) slightly
artificial DoFinishOrCancelEditing() unnecessary, so it can be removed,
without reintroducing any code duplication.
See #17835.
Previously this event was not sent at all if editing the item was
cancelled, e.g. by pressing Esc.
Do send it now from the generic implementation and update the sample to
show this event.
See #17835.
This method should be only used when the edit is really cancelled, so it
doesn't need to take a boolean argument.
It should also use the same spelling as IsEditCancelled() (and for
consistency with the rest of wxWidgets API which uses British English).
Also remove this method from the documentation, it is not part of the
public API.
Don't disable all inert renderers as this results in ugly "disabled"
look for some of them (see 6e885992f5),
but do disable the renderers that would be editable otherwise, such as
wxDataViewChoiceRenderer and wxDataViewToggleRenderer, in wxOSX as it
shouldn't be possible to change value of the inert cells.
See https://github.com/wxWidgets/wxWidgets/pull/707Closes#18056.
Replace the use of wxList macros with wxVector.
Also make wxDataViewTreeStore::Compare() slightly more efficient by
iterating over the children list only once instead of doing it twice.
This is a check for a programming error and should never be shown to the
user, so assert that the items being compared in wxDataViewTreeStore are
under the same parent instead of using wxLogError.
Don't use deprecated macro-based linked list class, use wxVector<>
instead for m_notifiers.
Also make it private, as it should have been from the beginning.
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 could be unexpected as it seems reasonable that the model won't be
ever asked about the value of a cell if it's not going to appear in it
anyhow -- however it could still happen during the column width
computation in the generic wxDataViewCtrl implementation.
Fix this in a minimally invasive way by just skipping the call to
GetValue() in this case.
Fix comparing items with checkboxes in wxTreeListCtrl and make it
simpler to correctly implement item comparison in other
wxDataViewCtrl-derived classes.
See https://github.com/wxWidgets/wxWidgets/pull/558
Export this class, which was only used internally by wxTreeListCtrl
before, so that user code can use it for its own columns with custom
wxDataViewCtrl models.
Add wxDataViewRenderer:: SetValueAdjuster() and a
wxDataViewValueAdjuster class. This can be used to customize rendering
of values depending on whether they are highlighted (selection) or not,
without having to implement an entire new custom renderer.
Since wxDataViewCtrlAccessible::GetName() calls to wxDataViewIconTextRenderer::GetAccessibleDescription() to directly retrieve the content of the renderer, there is no need to override wxDataViewCtrlAccessible::GetName() in order to get a proper content of the renderer in wxDataViewTreeCtrl.
The purpose of this method is to provide a textual description of the renderer's content to the class implementing accessibility framework in wxDVC (wxDataViewCtrlAccessible).
It is exposed if wxUSE_ACCESSIBILITY is set to 1.
Don't apply alignment to native controls in SetAlignment() method, where
it may not be known yet due to column-to-renderer inheritance if
wxDVR_DEFAULT_ALIGNMENT is used (the default). Move such code to
GtkUpdateAlignment() (which was made virtual) in all renderers.
This fixes unintended right-aligning of columns with GTK+ 2 when default
alignment was used.
It doesn't make much sense to always use wxCONTROL_FOCUSED in wxDataViewCtrl
code whenever wxDATAVIEW_CELL_SELECTED state bit is set, wxCONTROL_SELECTED
seems to be enough and is with the native MSW wxRenderer implementation which
doesn't even test for wxCONTROL_FOCUSED anyhow, while the generic one did and
didn't use the correct colour unless it was set.
No real changes, but this will make upcoming commits more straightforward and
already simplifies the code a little bit.
This solves the same problem as daa8fd03f3 did
for the GTK+ native version and ensures that the variant type at the renderer
level is consistent with the type of the values actually used with this
renderer (which are integers as they are indices).
Closes#17474.
Check the value of the wxDataViewCtrl pointer parameter in Init() instead
of unconditionally calling GetModel() on it. The default ctor of
wxDataViewEvent calls Init() with a null pointer.
This fixes the failing GUI tests with the XP buildbot slave.
Regression since 9829446755.
Also see #12649.
Expand() called ExpandAncestors() in the generic wxDataViewCtrl implementation
but not in the native ones, resulting in observable difference in the
behaviour: for example, the wxDataViewTreeCtrl in the dataview sample appeared
initially expanded under MSW, using the generic version, but collapsed under
GTK and OSX.
Harmonize this among all ports. This also has a nice side effect of making
Expand() less horribly inefficient as it is not recursively called by
ExpandAncestors() which it itself used to call: now ExpandAncestors() only
calls DoExpand() which is a simple function that only expands the item passed
to it and does nothing else.
Closes#14803.
Partially undo the changes of e417913f46 and set
m_item in StartEditing() as it's supposed to be already set when
CreateEditorCtrl() is called and setting it in NotifyEditingStarted() was too
late for this.
Take care of all the common stuff such as setting the event object and the
model, which is used for all events, in the ctor. Also set both the column
pointer and the column index at once instead of having two separate setters
for them which could result in inconsistent event objects (and did, as
sometimes only one or only the other field was set).
This makes the code shorter (we save 160 lines) and more clear and ensures
that everything is always initialized.
Closes#12649.
Using wxELLIPSIZE_END together with wxALIGN_RIGHT resulted in unnecessarily
ellipsizing or truncating the column contents in generic wxDataViewCtrl under
MSW due to the combination of b642747fd2 and
the native API behaviour.
Fix this by not using alignment in RenderText(): it is unnecessary anyhow and
not doing it avoids the problem as a side effect.
Closes#17363.
No real changes, just some cleanup to ensure that the item being edited stored
in wxDataViewRendererBase never refers to an item which is not, actually,
being edited any longer.
When using a custom renderer, wxEVT_DATAVIEW_ITEM_EDITING_STARTED was sent
twice: once from the generic base class StartEditing() and another time from
the GTK-specific "editing_started" signal handler. And we must send it from
the latter, because otherwise no event would be generated at all for the
standard renderers (i.e. text cells) for which we don't call StartEditing()
ourselves, so don't call it from the former and instead generate the event by
explicitly calling NotifyEditingStarted() after calling StartEditing() in the
generic version (as for wxOSX version, it doesn't use StartEditing() at all
and so doesn't need to be changed).
Reuse the same code from the generic and native GTK and OS X implementations
of wxDataViewCtrl instead of triplicating it.
This fixes a small discrepancy between the wxOSX version, which didn't see the
model pointer correctly in the generated event, and all the others, but mainly
paves way for future improvements.
We need to delete the editor control even if GetValueFromEditorCtrl() failed
as otherwise we're never going to be able to edit another item again, at least
with the GTK native implementation, which does nothing when starting to edit
an item if an editor control already exists.
While Enter and Tab on their own should be used to finish cell editing, the
cell editor itself may want to process key combinations involving these keys
with modifiers, e.g. Shift-Enter, so don't intercept those in at least the
generic version of wxDataViewCtrl to allow catching them in the editor.
