ANN : Enhanced wxTreeListCtrl

[jms]

I think modifiying the existing code to use wxBufferedPaintDC should require lot of changes in lot of places. If you have time, can you please have a look the control and suggest where I can use the wxBufferedPaintDC ? If so, I can send my modified copy that uses mouse move event to paint the headers.

It should not be that complicated. Your download link above is broken currently, so I can't suggest direct modifications, but basicly just call SetBackgroundStyle(wxBG_STYLE_CUSTOM) in constructor of any window being double-buffered, and then use wxBufferedPaintDC instead of wxPaintDC. You possibly need to use wxBUFFER_VIRTUAL_AREA as style in the dc constructor (see wx docs for more).

Also, unless you specify bitmap for the dc constructor, wx allocates a temporary bitmap at every dc creation, so for performance purposes you may want to pre-allocate one (it can be done in OnPaint). In my experience, a single bitmap is sufficient for all your windows.

And of course, when using buffered DCs you need to always paint your own background, if needed.

[aval57]

Hi,

A great widget tailor-made for my requirements, but I'm having a few issues in wxDev-C++ 6.10:

• The auto-generated call to AddColumn() had the positions of parameters 2 and 3 reversed, so I made the call manually instead; so far so good.

• wxTR_SHOW_ROOT_LABEL_ONLY is included in the wxForm Treelist styles list but isn't passed through to the auto-generated section of CreateGUIControls(). Adding it manually causes an 'undeclared' error.

So I tried to get an enhanced/updated wxtreelistctrl by compiling your 'treelisthead.dev' project, first from 'wxtreelistctrl_current.zip' and then from 'wxtreelistctrl.zip', but got compile errors in both cases, some of which were simple (e.g. wxcombobox.h needed to be #included), some less so (e.g. HDS_HOTTRACK undeclared, no matching function for call to `treelistheadDlg::cbMakeColumnEditable(wxCommandEvent)') .

I should add btw that I built and ran your 'wxtreelistctrl.zip' version in Fedora Core 5 using gcc 4.1.1 successfully earlier today, but the 'wxtreelistctrl_current.zip' version failed to compile same as in wxDev-C++.

So the short questions are: have you tried compiling either version of 'treelisthead.dev' in a standard installation of wxDev-C++ 6.10/mingw? Is there a newer version that might resolve the issues above?

Any guidance would be appreciated.
Bahman

[gururamnath]

Hi,
Sorry for the late reply. I'll check why the Show root flag is not passed.
The current distribution is a unstable version, Please use the stable version from .
http://twinforms.com/wxlib_wxtreelistctrl.htm

Thanks,
Guru Kathiresan

[aval57]

No apology necessary! Your plate is pretty full right now, I imagine. I did switch back to 'wxtreelistctrl.zip' after posting the message above and had to make a couple of changes to get it to compile with mingw:

Code: Select all

// treelistctrl.h - [line 27] (for HDS_HOTTRACK, etc.)
  #ifdef __WXMSW__    
      #define _WIN32_IE	0x0400  // *MINGW PATCH*
      #include "commctrl.h"
  #endif  

// treelistctrl.cpp - wxTreeListHeaderWindow CTOR [line 1196] (mingw GetHwnd() doesn't take an argument)
  #if defined(__WXMSW__) 
	m_hndlHeader = DoCreateHeader((HWND)win->GetHandle());  // *MINGW PATCH*
 	/*m_hndlHeader = DoCreateHeader(GetHwnd(win));*/	
  #endif    	    

I ran into a couple of issues (possibly mingw-specific, you would know best) once I started using wxtreelistctrl which I note here just for the record:

• 1. column 0 is always the last column:

  Code: Select all

  // treelistctrl.cpp -  in wxTreeListHeaderWindow::AddColumn() [line 1633]
   #if defined(__WXMSW__) 
    	int inPos = m_columns.GetCount();
  	if (inPos != 0) // this sends column 0 always to the far right!
  		inPos = inPos - 1;
    	DoInsertItem(m_hndlHeader,inPos,colInfo.GetWidth(),(char *)colInfo.GetText().c_str());
    #endif        	
  

• 2. If a vertical scrollbar is scrolled down in the main window any subsequent refresh-inducing action, such as changing the window size, reveals that the header window has also scrolled down internally, and the headings are now either out of view or only partially visible.

I also have a small suggestion to generalize wxTR_SHOW_ROOT_LABEL_ONLY so as to allow any cell to overwrite its empty neighbors like your typical spreadsheet; something like:

Code: Select all

// add to wxTreeListMainWindow::PaintItem()
// *PATCH* --------------------------------------------------------------------
		if ( IsFlagSet( wxTR_OVERWRITE_EMPTY_CELLS ) )
		{
			int c;
			for( c = i+1; c < GetColumnCount(); c++ )
				if( GetItemText( item, c ) == wxEmptyString )
					cx2 += m_owner->GetHeaderWindow()->GetColumnWidth( c );
				else break;
			cx1 = x_colstart; cy1 = item->GetY(); cy2 = total_h;
		}
// ----------------------------------------------------------------------------
		wxDCClipper clipper (dc,cx1,cy1,cx2,cy2 ); // only within column or the whole

Many thanks for all the effort and the untold time saved for the rest of us,
Bahman

[ultim8]

Thanks for the patch. I merged Guru's unstable release with the current release found in wxCode to get native headers (I left out the extra in-place editors for the moment though). With your patch, this widget is now even more useful. Thank you very much.

[eulalie]

Hi,

I would like to know user experience about using wxTreeListCtrl in virtual mode ; in which manner do you use it ? for which purpose ? what is the gain ?

It seems that this control is not fully virtual as in this mode you don't just fix the items count ,but you really add items in the tree ; the only thing is that you do not SetItemText for each column but this is the job of the callback OnGetItemText.
Indeed for a complete virtual control we have to forget about wxTreeListItem and transform each of the wxTreeListItem functions by a callback. Do you thing it's possible compare to the current version ? ( risk of potential bugs and regression ).

Thank you for your experience

[frm]

Hi Guru,
I wonder if you are interested in integrating wxTreeListCtrl directly into wxWidgets itself...

wxDataViewCtrl classes are part of wx28 and they do work nicely under wxGTK (using a native control); however they look bad under wxMSW where they use generic version. I'm sure that your changes to wxTreeListCtrl could be generalized to wxDataViewCtrl as well making it look almost completely native also under win32.

Please look at the "proposal of new widgets: wxTreeListCtrl and wxReportListCtrl" msg on wx-dev: for wxTreeListCtrl I'd like to basically merge Otto's wxTreeListCtrl in wx rewriting it to use wxDataViewCtrl and then to merge your changes about native rendering of the header window into wxDataViewCtrl itself.

If you are interested, please let me know (my mail is f18m_cpp217828 _at_ yahoo.it).

It would really be awesome to have wxDataViewCtrl look nice on win, too and then have wxTreeListCtrl, finally native, part of wx itself!

Francesco

[gururamnath]

Hi Francesco,

I wonder if you are interested in integrating wxTreeListCtrl directly into wxWidgets itself...

Yes, I would luv to help integrating it.

Couple of things I want to mention before contributing to this one (and want to know your opinion).

1)When working with the wxTreeListCtrl, I went through the wxDataViewCtrl code and found that the wxDataViewCtrl's implementation is ripped from wxTreeListCtrl except for the Tree Implementation and the way each cell is constructed/painted. I'm wondering if we can have the tree implementation in wxDataViewCtrl and people can once for all abandon wxTreeListCtrl and contribute to wxDataViewCtrl ?

2)The latest wxTreeListCtrl in wxCode already has a native header implementation using wx functions. Couple of months back Robin Dunn has patched it with the wxRenderNative functions to make the header native. Since mine is specific to Windows only, I think his solution will be a better one and will work in all platforms.

-regards,
Guru Kathiresan

[frm]

1)When working with the wxTreeListCtrl, I went through the wxDataViewCtrl code and found that the wxDataViewCtrl's implementation is ripped from wxTreeListCtrl except for the Tree Implementation and the way each cell is constructed/painted. I'm wondering if we can have the tree implementation in wxDataViewCtrl and people can once for all abandon wxTreeListCtrl and contribute to wxDataViewCtrl ?

this is exactly the idea. To be honest my idea is that wxDataViewCtrl API is not as straightforward to use as wxTreeListCtrl's one (e.g. because you need to derive your own model from wxDataViewModel all the times) and that we'll thus need to write at least two helper classes: wxReportListCtrl and wxTreeListCtrl which will act as fa

[Aladdina]

Very nice. Thanks a lot.

I got a defect in the function "MakeShortString". The length of "szShort" might not be long enough, and it makes my application crash. There are two places:

1. wcscpy might write invalid memory.
2. lstrcat might write invalid memory.

Thanks.

[tl20lee]

Hi,

It would be nice if you can handle checkboxes as well textctrls as if wxGrid does. And also creating all the EventHandlers available in the ListCtrl to be available in here, too. Any progress on this?

Thanks,

[gururamnath]

It would be nice if you can handle checkboxes as well textctrls as if wxGrid does. And also creating all the EventHandlers available in the ListCtrl to be available in here, too. Any progress on this?

Even I would luv to have such feature. Currently the architecture of the wxTreeListCtrl does not support rendering each cell separately. I made some changes for the inplace editors (text and combo) but they are very crude.

-Guru Kathiresan
http://www.twinforms.com
wxWidgets Form Designer for C++ Builder

[Infinity_77]

Hi,

It would be nice if you can handle checkboxes as well textctrls as if wxGrid does. And also creating all the EventHandlers available in the ListCtrl to be available in here, too. Any progress on this?

Thanks,

Switch to wxPython:

http://xoomer.alice.it/infinity77/main/ ... ertreelist



Andrea.

[gururamnath]

Switch to wxPython:

http://xoomer.alice.it/infinity77/main/ ... ertreelist



Andrea.

I'm not sure how people will migrate to wxPython just for this control ).
Anyway, your approach for adding controls in interesting. I'll try to port the control addition code to the C++ version.

Thanks,
Guru Kathiresan

[Infinity_77]

Switch to wxPython:

http://xoomer.alice.it/infinity77/main/ ... ertreelist



Andrea.

I'm not sure how people will migrate to wxPython just for this control ).

Of course it was a joke
I am surely not expecting wxWidgets users to switch to wxPython, though I still have to find a single reason why I should choose wxWidgets (C++) over wxPython (Python). But then, that's only my personal opinion.

Anyway, it's not "just for this control". If you ever looked at wxPython wx.lib and http://xoomer.alice.it/infinity77/main/freeware.html you might probably see a gazillion of custom/owner-drawn widgets readily available in Python, most of them not implemented in wxWidgets (C++). That could be a reason for someone to choose wxPython over wxWidgets. It sure is for me . But then, again, it's just a matter of taste.

Anyway, your approach for adding controls in interesting. I'll try to port the control addition code to the C++ version.

The original code for that comes from CustomTreeCtrl:

http://xoomer.alice.it/infinity77/main/ ... omtreectrl

Which is a very big revisiting of the generic C++ wxTreeCtrl. HyperTreeList has not been widely tested, and I am pretty sure some bugs is there

Andrea.