Introduction
This posting is to update an existing posting by someone else (http://www.codeproject.com/cs/miscctrl/extendedlistviews.asp).  This post by Jon Rista was a great foundation but invetiably, it had bugs.  As Jon doesn't seem to be mainting his post, I thought I'd help some of the people who originally downloaded his control to be able to use a version that has the bugs I've found fixed.

Why fix this control?
There are several other treeview/listview combo controls posted to Code Project so why fix this one?  The attraction of the control, to me, is that it is entirely in C#.   We are developing an application and want to deliver a product that is all managed C# code.  Most of the other implementations combine the existing Treeview and Listview controls and these, in our view, have three main draw backs:

They are COM not managed code
The source is not available so the appearance is determined by the authors (MS) not us
They were not designed to be used side-by-side
Another attraction is that Jon included hooks for the ability of the treenodes to be compose of other objects.  These might be a listview with a different set of columns, another treeview or a textbox.  Pretty visionary!

What has been fixed?
We noticed several bugs:

The columns titles were sized and displayed incorrectly (you can see this in the images presented in Jon's article
The control Jon devised allows a user to include another control however the painting of the embedded control was not always correct
The mouse and keyboard movement had focus problems and, under some circumstances, the focus row would jump rows
Addressing these issues, especially the the mouse and keyboard event handling, has meant fairly substantial changes.

In his original artical, Jon pointed out that the drawing routine called by the paint method was inefficient.  This is because the routine computed the rows to show in the viewport by counting the rows each time.  This is not an issue on a small or entirely collapsed list, but is an issue with larger lists.  Addressing this issue has, again, meant fairly substantial changes.  For example, the drawing routine is almost entirely rewritten and this was necessary because of the way the display size is now handled.

Now when a node is added or an exising node is expanded, collapsed or removed, it's parents are notified and so they are able to maintain a note of the number of decendent nodes and the number of them that are expanded.  The new drawing routine uses this additional information to workout what to draw and can do so more efficiently.  The drawing routine, which is called often, is no longer affected by the length of the list as the work to maintain the node counts occurs as nodes are added, removed, expanded or collapsed.

While these changes will help performance, they can slow the process of creating the tree list in the first place.  To address this, the control now exposes a BeginUpdate() method that can be called prior to adding any significant number of items.  When the EndUpdate() method is called, the node values are recomputed and the control can be displayed.

Is this control now perfect?
Probably not.  Infact in getting ready to post this article, I think I saw a bug that occurs when a call to ExpandAll() is used more than once.  We intend to use this control (we've not done so yet) so please let me have a note of any issues you find.  If you do report any problems, please make sure you tell me where to find the problem.  If you have a program that illustrates the problem, please send it to me.