Windows Forms Control Development example: expanding the TreeView

Summary: Describes how to add data-binding functionality to the TreeView control, which is one of a series of Microsoft Windows control development examples. You can read this article in conjunction with the relevant overview article.

Brief introduction

When possible, you should use ready-made controls first, because the microsoft®windows® form controls you provide contain a lot of coding and test results, which is a huge waste if you want to give them a start from scratch. Based on this, in this example, I will inherit an existing Windows forms control TreeView and then customize it. When you download the code for the TreeView control, you will also get additional control development examples and a sample application that demonstrates how to use the enhanced TreeView with other data-bound controls.

Designing a data-binding tree view

Adding data binding to the TreeView control is a common problem for Windows developers, but because the TreeView and other controls (such as a ListBox or a DataGrid) have a major difference (that is, the TreeView displays hierarchical data), the basic controls This feature is not currently supported (that is, we must also use it). Given a datasheet, you know exactly how to display that information in a ListBox or DataGrid, but using the layered features of the TreeView to display the same data is less straightforward. Personally, I have used many different methods when displaying data in the TreeView, but one method is most commonly used: grouping data in a table by some fields, as shown in Figure 1.

Figure 1: Displaying Data in the TreeView

In this case, I'll create a TreeView control that passes a flat dataset (as shown in Figure 2) and makes it easy to generate the results shown in Figure 1.

Figure 2: Flat result set containing all the information needed to create the tree shown in Figure 1

Before I started coding, I figured out a design for the new control that could handle that particular dataset, and wanted it to work with many other similar scenarios. Add a collection of groups that you can use most of the flat data to create a hierarchical structure in which you specify a grouping field, display field, and Value field for each level of hierarchy (all or all fields should be the same). To convert the data shown in Figure 2 to the TreeView shown in Figure 1, my new control requires that you define two group-level publisher and Title, and define pub_id as a grouping field for the Publisher group, and define title_id as a part of the Title group Group fields. In addition to grouping fields, you need to specify display and value fields for each group to determine the text that is displayed on the corresponding group node and the value used to uniquely identify a particular group. When you encounter this type of data, use pub_name/pub_id and title/title_id as the Display/value fields for these two groups. The author information becomes the leaf node of the tree (the node at the end of the grouping hierarchy), and you also need to specify the ID (au_id) and display (au_lname) fields for those nodes.

When you build a custom control, it is helpful to make the control more efficient by determining how the programmer uses the control before you start coding. In this case, I want the programmer to be able to use the following lines of code to complete the grouping, given the data shown earlier and the desired results:

With DbTreeControl
.ValueMember = "au_id"
.DisplayMember = "au_lname"
.DataSource = myDataTable.DefaultView
.AddGroup("Publisher", "pub_id", "pub_name", "pub_id")
.AddGroup("Title", "title_id", "title", "title_id")
End With

Note: This is not the line of code I eventually wrote, but the two are not much different. As I developed the control, I realized that the image index in the ImageList associated with the TreeView needs to be associated with each grouping level, so you must add an extra parameter to the AddGroup method.

To actually build the tree, I'll browse through the data and look for changes to the fields (specified as grouped values for each group), create new grouping nodes if necessary, and create a leaf node for each data item. Because there are grouping nodes, the total number of nodes will be greater than the number of items in the data source, but each item in the underlying data has and only one leaf node.

Figure 3: Grouping nodes and leaf nodes

The distinction between leaf and grouping nodes (as shown in Figure 3) is important for the remainder of this article. I decided to treat the two types of nodes differently, create a custom node for each type of node, and raise different events based on the selected node types.