How to make item text read-only in a wxDataViewTreeCtrl

[Frédéric]

Hi,

I replaced a wxTreeCtrl by a wxDataViewTreeCtrl. This fixed some
issues I had and has a better looking on Windows. However, the item
texts can now be editable which I do not want. How can I set them to
read-only?

Kind regards,

F

[Igor Korot]

Hi, Frederic,

From the docs:

EVT_DATAVIEW_ITEM_START_EDITING(id, func):
Process a wxEVT_DATAVIEW_ITEM_START_EDITING event. This event can be
vetoed in order to prevent editing on an item by item basis.

Thank you.

>
> Kind regards,
>
> F
>
> --
> Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
>
> To unsubscribe, send email to wx-users+u...@googlegroups.com
> or visit http://groups.google.com/group/wx-users

[Vadim Zeitlin]

On Wed, 15 Aug 2018 17:42:57 +0200 Frédéric wrote:

F> I replaced a wxTreeCtrl by a wxDataViewTreeCtrl. This fixed some
F> issues I had and has a better looking on Windows.

This is funny because wxTreeCtrl is a native control there, while
wxDataViewTreeCtrl is not.

F> However, the item texts can now be editable which I do not want. How can
F> I set them to read-only?

There is no way to change wxDATAVIEW_CELL_EDITABLE used in this class
Create() currently, so vetoing the event, as already advised by Igor, is
the only way to do it. This being said, I'd recommend not using
wxDataViewTreeCtrl at all, it's a pretty weird class which is supposed to
be like wxTreeCtrl but actually isn't one. FWIW I'm writing a "real"
wxTreeCtrl implementation based on wxDataViewCtrl right now, so in a couple
of weeks you should be able to use it if you really want to have wxDVC look
(which, again, mostly makes sense under GTK+ and macOS, where it is native
and wxTreeCtrl is not, but if you prefer it under MSW too, why not...) with
wxTreeCtrl API.

And right now you could use wxTreeListCtrl which is also based on wxDVC
but has a nicer API.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Frédéric]

> F> I replaced a wxTreeCtrl by a wxDataViewTreeCtrl. This fixed some
> F> issues I had and has a better looking on Windows.
>
> This is funny because wxTreeCtrl is a native control there, while
> wxDataViewTreeCtrl is not.

When I test that on Windows 10, wxTreeCtrl looks old with + and - in
dashed square while wxDataViewTreeCtrl looks exactly the same as the
left pane of the Windows Explorer (the pane with the directory tree).
So it looks more native to me!

> FWIW I'm writing a "real"
> wxTreeCtrl implementation based on wxDataViewCtrl right now,
>

> And right now you could use wxTreeListCtrl which is also based on wxDVC
> but has a nicer API.

Thanks for wxTreeListCtrl which I did not see.
What will be the advantage of your new class compared to wxTreeListCtrl?

F

[TcT]

F> I replaced a wxTreeCtrl by a wxDataViewTreeCtrl. This fixed some
F> issues I had and has a better looking on Windows.

 This is funny because wxTreeCtrl is a native control there, while
wxDataViewTreeCtrl is not.

Regarding the look see the documentation http://docs.wxwidgets.org/trunk/classwx_tree_ctrl.html for wxTR_TWIST_BUTTONS.

wxDataView has the system theme enabled by default, where wxTreeCtrl does not have the system theme enabled by default.

That's probably the explanation for one looking more like the explorer.

[Frédéric]

> F> I replaced a wxTreeCtrl by a wxDataViewTreeCtrl. This fixed some
> F> issues I had and has a better looking on Windows.
>
> This is funny because wxTreeCtrl is a native control there, while
> wxDataViewTreeCtrl is not.

One problem with wxTreeCtrl that was fixed by wxDataViewTreeCtrl is
that wxTreeCtrl reserve space for an icon, even if there is no icon on
the item. This happens only in MSW. This is an issue for me as I have
icons only in the 3rd level of the tree. 1st and 2nd level therefore
look ugly! (tested with the official sample by the way).

F

[Frédéric]

> And right now you could use wxTreeListCtrl which is also based on wxDVC
> but has a nicer API.

Apparently this class misses an option to hide the header line!

F

[Vadim Zeitlin]

On Thu, 16 Aug 2018 09:41:49 +0200 Frédéric wrote:

F> Thanks for wxTreeListCtrl which I did not see.
F> What will be the advantage of your new class compared to wxTreeListCtrl?

It will be a wxTreeCtrl, i.e. 100% (hopefully; if not, then as close as
possible) API-compatible with the existing class. As part of this, it will
allow to add items to the tree on demand (the first time when a branch is
expanded) instead of having to add all of them at once, making it more
suitable for big trees.

F> Apparently this class misses an option to hide the header line!

wxTreeListCtrl is supposed to be simple and so its API is intentionally
limited, but perhaps we could add a style to avoid showing the header...

[David Connet]

On 8/16/2018 3:40 AM, Vadim Zeitlin wrote:
> As part of this, it will
> allow to add items to the tree on demand (the first time when a branch is
> expanded) instead of having to add all of them at once, making it more
> suitable for big trees.

I hadn't looked closely at the wxTreeCtrl api... I didn't realize this
wasn't available - it is at the native Windows API level.
(I_CHILDRENCALLBACK / TVN_GETDISPINFO / TVN_ITEMEXPANDING)

Dave

[Vadim Zeitlin]

On Thu, 16 Aug 2018 07:25:40 -0700 David Connet wrote:

DC> On 8/16/2018 3:40 AM, Vadim Zeitlin wrote:
DC> > As part of this, it will
DC> > allow to add items to the tree on demand (the first time when a branch is
DC> > expanded) instead of having to add all of them at once, making it more
DC> > suitable for big trees.
DC>
DC> I hadn't looked closely at the wxTreeCtrl api... I didn't realize this
DC> wasn't available - it is at the native Windows API level.
DC> (I_CHILDRENCALLBACK / TVN_GETDISPINFO / TVN_ITEMEXPANDING)

It is available in wxTreeCtrl, but not in wxTreeListCtrl.

[David Connet]

On 8/16/2018 10:19 AM, Vadim Zeitlin wrote:
> It is available in wxTreeCtrl, but not in wxTreeListCtrl.

Headthump (E_CONTEXT_FAILURE). Caffeine must be running on a delayed circuit...

Dave

[Frédéric]

> I'd recommend not using
> wxDataViewTreeCtrl at all, it's a pretty weird class which is supposed to
> be like wxTreeCtrl but actually isn't one.

For me it works much better than wxTreeCtrl because I do not have icons
in each level of my tree and levels without icons are ugly on Windows
with wxTreeCtrl (a free space is left and the dashed line is not continued).
So my question to you Vadim: is there any risk by adopting
wxDataViewTreeCtrl? When you say "I'd recommend not using
wxDataViewTreeCtrl", are you warning me from potential future issues I
would discover or if it does what I want, I am safe with it?

This being said, I would like to use the generic version of
wxDataViewTreeCtrl on all platforms because it behaves better when all
levels do not have icons: on GTK3, when I create the wxDataViewTreeCtrl
in collapsed state and the top item does not have an icon, the text is close
to the arrow, fine.
When I open the top item, as soon as an item with icon is shown, all items
save the space for an icon which looks bad when there is no icon to show.
This does not happen with the generic control on MSW and this is why I
would like ot use it everywhere.

How can I use the generic version of wxDataViewTreeCtrl on all platforms?
I tried to#include <wx/generic/dataview.h>
instead of #include <wx/dataview.h>
but got plenty of compilation errors like:
/softs/lin64-gcc-8.2.0/release/wx/include/wx-3.1/wx/generic/dataview.h:35:1:
error: expected class-name before ‘{’ token
{
^
/softs/lin64-gcc-8.2.0/release/wx/include/wx-3.1/wx/generic/dataview.h:38:22:
error: ‘wxDataViewRenderer’ has not been declared
wxDataViewRenderer *renderer,
^~~~~~~~~~~~~~~~~~
/softs/lin64-gcc-8.2.0/release/wx/include/wx-3.1/wx/generic/dataview.h:50:22:
error: ‘wxDataViewRenderer’ has not been declared
wxDataViewRenderer *renderer,
^~~~~~~~~~~~~~~~~~
/softs/lin64-gcc-8.2.0/release/wx/include/wx-3.1/wx/generic/dataview.h:61:18:
error: ‘virtual void wxDataViewColumn::SetTitle(const wxString&)’
marked ‘override’, but does not override
virtual void SetTitle(const wxString& title) wxOVERRIDE
^~~~~~~~

Kind regards,

F

[Vadim Zeitlin]

On Mon, 27 Aug 2018 13:57:43 +0200 Frédéric wrote:

F> > I'd recommend not using
F> > wxDataViewTreeCtrl at all, it's a pretty weird class which is supposed to
F> > be like wxTreeCtrl but actually isn't one.
F>
F> For me it works much better than wxTreeCtrl because I do not have icons
F> in each level of my tree and levels without icons are ugly on Windows
F> with wxTreeCtrl (a free space is left and the dashed line is not continued).

I understand this, but you still shouldn't use this class, it risks being
deprecated in the future wxWidgets versions. Use wxTreeListCtrl if you can
(i.e. don't have too many items) or wxDataViewCtrl directly instead.

F> How can I use the generic version of wxDataViewTreeCtrl on all platforms?

I'm not sure if this is supported now, but you could try predefining
wxHAS_GENERIC_DATAVIEWCTRL when building both the library and your code.

[Frédéric]

> Use wxTreeListCtrl if you can (i.e. don't have too many items)

So I came back to this solution and started to implement the missing
wxTL_NO_HEADER which is the only thing that was missing for me. And I
discovered that it was already implemented but not documented.
What makes it come in the doc?
I found that in include/wx/treelist.h:42:
enum
{
wxTL_SINGLE = 0x0000, // This is the default anyhow.
wxTL_MULTIPLE = 0x0001, // Allow multiple selection.
wxTL_CHECKBOX = 0x0002, // Show checkboxes in the first column.
wxTL_3STATE = 0x0004, // Allow 3rd state in checkboxes.
wxTL_USER_3STATE = 0x0008, // Allow user to set 3rd state.
wxTL_NO_HEADER = 0x0010, // Column titles not visible.

and that in interface/wx/treelist.h:16:
enum
{
wxTL_SINGLE = 0x0000, /// This is the default anyhow.
wxTL_MULTIPLE = 0x0001, /// Allow multiple selection.
wxTL_CHECKBOX = 0x0002, /// Show checkboxes in the first column.
wxTL_3STATE = 0x0004, /// Allow 3rd state in checkboxes.
wxTL_USER_3STATE = 0x0008, /// Allow user to set 3rd state.
/**
Don't show the column headers.

By default this control shows the column headers, using this class
allows to avoid this and show only the data.

@since 2.9.5
*/
wxTL_NO_HEADER = 0x0010,

but no trace of wxTL_NO_HEADER here:
http://docs.wxwidgets.org/trunk/classwx_tree_list_ctrl.html#a844c05440a63f6cf04b36aab91e9449e

I am OK to prepare a PR but what should I modify?

Thanks,

F

[Vadim Zeitlin]

On Tue, 28 Aug 2018 17:02:58 +0200 Frédéric wrote:

F> > Use wxTreeListCtrl if you can (i.e. don't have too many items)
F>
F> So I came back to this solution and started to implement the missing
F> wxTL_NO_HEADER which is the only thing that was missing for me. And I
F> discovered that it was already implemented but not documented.

Actually, it is at

http://docs.wxwidgets.org/trunk/treelist_8h.html#a900dca9b26de42491763226e12dcd47ba21b614dc4bbc75612decf259b5d4c20f

but not in wxTreeListCtrl documentation itself.

F> but no trace of wxTL_NO_HEADER here:
F> http://docs.wxwidgets.org/trunk/classwx_tree_list_ctrl.html#a844c05440a63f6cf04b36aab91e9449e

The styles are documented separately and in wxTreeListCtrl documentation.
This doesn't seem like a good idea to me, as it can result in problems like
the one you've just found, but I don't have any good solution right now, so
I've just duplicated the documentation of this one as well in

https://github.com/wxWidgets/wxWidgets/commit/783b82913b7e7191d4c575fe725c91c911a45239

Thanks for noticing this and sorry for forgetting that it was already
implemented,

[Frédéric]

> Actually, it is at
> http://docs.wxwidgets.org/trunk/treelist_8h.html#a900dca9b26de42491763226e12dcd47ba21b614dc4bbc75612decf259b5d4c20f

Now I can see it, yes.

> but not in wxTreeListCtrl documentation itself.

> I've just duplicated the documentation of this one as well in
>
> https://github.com/wxWidgets/wxWidgets/commit/783b82913b7e7191d4c575fe725c91c911a45239

That looks fine, thanks for the commit.

Kind regards,

F