Updated Extended ListView

• Download source files - 110 Kb
• Download demo - 71.8 Kb

Introduction

This posting is to update an existing posting by someone else (ContainerListView and TreeListView: Writing VS.NET design-surface compatible controls). The previous post by Jon Rista was a great foundation but inevitably, it had bugs. As Jon doesn't seem to be maintaining 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.

Please note that the code attached to this article has been modified using VS.NET 2003. If you want to use the code in the earlier version of VS.NET, you will need to create new .csproj and .sln files.

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 tree nodes to be composed 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:

1. The column titles were sized and displayed incorrectly (you can see this in the images presented in Jon's article
2. The control Jon devised allows a user to include another control, however the painting of the embedded control was not always correct
3. 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 article, 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 existing node is expanded, collapsed or removed, its parents are notified and so they are able to maintain a note of the number of descendent 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. In fact 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.