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
Add wx/gtk/private/wrapgtk.h wrapping gtk/gtk.h in pragmas disabling
these warnings and include it everywhere instead of directly including
gtk/gtk.h.
Also include wx/gtk/private/gtk2-compat.h from this wrapper header as it
was included by 90% of the files including gtk/gtk.h itself and it seems
to be better and simpler to just always include it.
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.
The code was more complicated than necessary, with the base class
providing both virtual GtkOnCellChanged() and GtkOnTextEdited() that
were both overridden to achieve the same thing, namely customizing how
the value entered by user is converted to wxVariant, in different
derived classes.
Make GtkOnTextEdited() non-virtual and remove GtkOnCellChanged()
completely and add a new simple GtkGetValueFromString() which is called
from GtkOnTextEdited() to do the conversion.
This removes the existing code duplication and will make it simpler to
modify this code in the future, without changing the behaviour.
There is an impedance mismatch between wxDataViewCtrl API, which allows
deleting all items of the model at once, and GtkTreeView, which only
allows deleting them one by one, so bad things happen when we start
deleting the items from the GTK+ model after already having deleted them
from the wxDataViewModel, due to dereferencing the already freed
pointers.
Work around this by explicitly marking the model as being "temporarily
unsafe to use" by setting the stamp, uniquely identifying it, to 0 (and
ensuring that it's never 0 during the normal operation), and checking
for it in all functions that are called by GTK+ from inside
gtk_tree_model_row_deleted() that we call from Cleared().
The fix is not ideal, as the list of these functions was determined
empirically and could change in the future GTK+ versions, and also ugly,
but there doesn't seem to be any other way around this and at least now
Valgrind doesn't report invalid memory reads after calling
wxTreeListCtrl::DeleteAllItems() as it did before.
Using GtkBin as widget parent didn't work without overriding its
size-related vfuncs until GTK+ 3.8 and, in particular, resulted in the
editor (which was the child of the bin) not being visible at all with
GTK+ 2.
Switch to using GtkHBox as parent, which does work with both GTK+ 2 and
any GTK+ 3 version, but keep using GtkBin with GTK+ 4 as GtkHBox is
removed in it.
This fixes bug introduced in c2821dcea0
since which custom wxDataViewCtrl editors were not visible any more.
Closes#17686.
No real changes, just don't call gtk_wx_cell_renderer_get_size()
unnecessarily as we never use its result: the code using the returned
rectangle was commented out ever since it was added (more than 10 years
ago) in 1e510b1e2d
No real changes, just don't define macros that we never use and don't
plan on using it (why would we need to test whether something is of this
type when we already know it).
Use wx_is_at_least_gtk2(minor) instead of gtk_check_version(2, minor)
because it is more clear and also works as expected (i.e. returns true)
when using GTK+ 3 instead of creating difficult to notice bugs in the
code by failing the version check in this case.
See #18004.
This replaces the changes of 24c0401e81
which, for some reason, used a global variable for storing whether the
selection function had been already set or not, when this clearly is a
per-control (or per-selection, but this seems one and the same) bit of
information.
Replace global ms_firstTime with a wxDataViewCtrlInternal field to avoid
asserts as soon as EditItem() is called on more than one wxDataViewCtrl.
Closes#17946.
Asserting before dereferencing a null pointer (in BuildBranch(), called
immediately after the asserts in question) is useless, as usual. Use wxCHECK
to complain and avoid crashing instead.
Closes#17776.
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.
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.
In both the generic and GTK+ implementations, setting the value of a
bitmap column to wxNullVariant resulted in the bitmap, if set for some
rows, being repeated on the rows with null value.
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.
The code handling background colour was commented out for some reason, simply
enable it as it seems to be working just fine -- and update the sample to show
that it does.
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 this column type made the control even slower for a big number of items
and also prevented the user from resizing the column which was unexpected.
See #16680.
Previously the editor created by wxDataViewRenderer::CreateEditorCtrl() had to
be a native GTK+ widget implementing GtkCellEditable interface which prevented
using composite windows (e.g. a container for a text control and a button) as
editors.
Create a helper container wrapping them now and implementing GtkCellEditable
now to allow this.
Call FinishEditing() when the cell is done being edited instead of sending
wxEVT_DATAVIEW_ITEM_EDITING_DONE event manually from wxGTK code.
This fixes the bug with not being able to edit an item the second time if the
editor was dismissed by GTK+ itself and not by our own code (which already did
call FinishEditing()) as the old editor still remained alive because
DestroyEditControl(), usually called from FinishEditing(), wasn't executed.
It also removes code duplication and avoids the need to keep a global
s_user_data pointer as the item currently being edited is already stored in
wxDataViewRenderer anyhow.
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.
wxOSX and wxGTK previously used their own methods for handling the enabled
state and the attributes of the items being rendered, change them to reuse the
same methods as the generic implementation, i.e. SetEnabled() and SetAttr()
and remove the port-specific GtkSetAttr(), OSXApplyAttr() and so on.
This has the advantage of ensuring that the logic is the same for all
platforms (e.g. item enabled status wasn't handled in the same way in wxGTK as
in the other ports previously) and hopefully makes the code simpler by cutting
down on the number of virtual methods.
Notice that GtkSupportsAttrs() optimization was removed as it didn't seem to
be worth the bother (we basically saved a call to a virtual model method at a
price of a virtual renderer method call) and preserving it would have
complicated things needlessly.
Move the checks for the type mismatch between the type of the value returned
by wxDataViewModel and the type expected by wxDataViewRenderer into common
code. This avoids duplicating the same code in wxGTK and wxOSX and, more
importantly, means that this check is also performed in wxMSW when using the
generic version, so that the problems such as the one fixed in 3ff8c3c ("add
missing wxDataViewDateRenderer::GetDefaultType()") would be visible there too.
