LogoASPAlliance: Articles, reviews, and samples for .NET Developers
Extended TreeView
by G. Mohyuddin
Average Rating: 
Views (Total / Last 10 Days): 51288/ 155


It is a TreeView Control that has been extended from the ASP.NET TreeView shipped with .NET Framework 2.0. By extending it from the built in TreeView control, the purpose is to have all basic features of the existing TreeView with some new features, which are highly required but are not supported by the ASP.NET TreeView control. This article does not explain how to extend a TreeView control. That will be covered in a separate article, while this article primarily focuses on how to use this Extended TreeView.

Extended TreeView provides the following important functionalities which are lacking in ASP.NET 2.0 TreeView.

It saves its expansion state.

It is automatically bindable with Multiple sitemaps; also changeable dynamically.

It is bindable with a Database by providing connection string and other necessary information directly.

It is also bindable with dataset programmatically.

Using Extended TreeView

Here is the header of the Extended TreeView. It shows its name and default properties.

Listing 1

namespace ExtendedControls
namespace TreeView
  [ToolboxData("<{0}:XTreeView runat=server></{0}:XTreeView1>")]
   public class XTreeView : System.Web.UI.WebControls.TreeView

I will explain here how to use the aforementioned functionalities in Extended TreeView. Let us see them one by one.

Saving the Expansion State

The ASP.NET 2.0 TreeView does not persist in its expansion state. You can either collapse all or expand all the tree nodes. It really becomes troublesome when TreeView has a good number of nodes in multiple hierarchal levels. While navigating from one page to another, the hierarchal expansion state of the TreeView gets lost. Again, we have to expand it to that level and navigate to the desired pages. It becomes of no use when one wishes to have expansion state of TreeView maintained on post backs. Hence, the point comes to have this very crucial feature in TreeView. Extended TreeView supports this by default, you do not need do any thing.

Figure 1

Binding with Multiple Sitemaps

ASP.NET 2.0 TreeView is bindable with one sitemap per website only named with Web.sitemap. The ASP.NET Sitemap Provider only looks for a site map with this name. The only way to use multiple sitemaps is to nest the sitemaps, having the parent with same name, Web.sitemap. No matter even if you will add another TreeView control on page, it again expects the Web.sitemap. It does not work in salutations where we want to customize the look of a tree view according to the category. The Extended TreeView works great for us and overcomes this problem. Now we can use as many sitemaps as we wish in a website (without nesting) and can bind them with their corresponding XTreeViews. 

To work with multiple sitemaps follow these steps.

Add a new sitemap to your web site and name it, say CommonUser.sitemap. Save it in any folder, preferably App_Data for security reasons. This will not allow the client to see it. All contents of this folder are inaccessible to the client.  

Add nodes and set their properties in the sitemap file as shown below.

Listing 2

<?xml version="1.0" encoding="utf-8" ?>
  <siteMapNode value="~/Home.aspx" title="Home">
  <siteMapNode  value="~/Default.aspx"  title="User Tasks" >
    <siteMapNode value="~/Profile.aspx" title="View" >
    <siteMapNode value="~/Profile.aspx" title="Profile" />
    <siteMapNode value="~/WeeklyWorkTimeDetail.aspx" title="Work Time Detail" >
        <siteMapNode value="~/WeeklyWorkTimeDetail.aspx" title="Weekly"/>
         <siteMapNode value="~/MonthlyWorkTimeDetail.aspx" title="Monthly"/>
        <siteMapNode value="~/YearlyWorkTimeDetail.aspx" title="Yearly"/>
    <siteMapNode value="~/WarningComments.aspx" title="Warning and Comments" />

DO NOT use URL property of node, use Value property instead. By using URL browser, it transfers to the next page without making a server round trip that does not allow saving the expansion sate of the nodes on server. Yet by using VALUE property the page is redirected; a server round trip provides a chance to save the expansion state.

Drag the XTreeView control from the control bar and drop on the page.

Listing 3

<cc1:XTreeView ID="XTreeView1" runat="server">

From the Property pane you will see a new property category Sitemap, it has one property Sitemap. Browse and select it.  That is it. The following image shows this.

Figure 2

For more sitemaps repeat the steps listed above.

View the page in browser you will see that all TreeView are not only successfully bound with their corresponding sitemaps, but also persist their expansion state.

Figure 3

Binding with Database

Generally, binding a TreeView with database requires much to do with code. It requires opening connection, populating a dataset with all required tables and establishing the relationship between them. XTreeView minimizes this effort by providing you few properties to bind it with database directly. Before mentioning these properties, I would like to explain shortly the necessary information ASP.NET TreeView requires for binding with database. 

Generally binding a TreeView with database requires the following steps.                            

Open Connection

Populate Dataset with the parent table.

Populate Dataset with the child table if any.

Establish the relation between these two tables added to the dataset on the basis of the primary and foreign key relationship. (This can be achieved by taking a Relation object, instantiating it with parent child field information and adding it to the Relation collection of the Dataset.)

Repeat the previous two steps for each next child table if any. (The relation will be maintained between the current child and its immediate parent table.)

Now create the nodes of the tree recursively for each row of the Dataset’s parent table with all related rows of the Dataset’s child table under that primary key.

The following figure shows all the properties for XTreeView binding with database.

Figure 4


Now let us take a look at these properties that do the same job for us without writing any code. I have put these properties under a new category database in the property pane for the sake of simplicity and better understanding.

ConnectionString property is mandatory and required to be set with a valid connection string as shown below.

Listing 4

<cc1:XTreeView ID="XTreeView1" runat="server"
 ConnectionString="Data Source=gmohyd-serv;Initial Catalog=pakistan_db;Integrated Security=True"

Parent node has the following properties.

ParentTableName:  Name of the parent table.  (Mandatory)

ParentNodeTextField: Name of the field of parent table to be displayed as the node text. (Optional, if not set XtreeView takes the second column as node text field.)

ParentNodeValueField: Name of the field of parent table that has to be set as value. Value field can be used for saving page URL's if required, otherwise it is suitable to save ID's. (Optional, if not set, XtreeView takes the first column as node text field.)

ParentChildRelationField:  Name of the field (primary key) of parent table that is being used as foreign key in child table. (Mandatory if there is some child of it.)

The child has the following properties.

ChildTableName:  Name of the Child table.  (Mandatory)

ChildNodeTextField: Name of the field of Child table to be displayed as the node text. (Optional, if not set, XtreeView takes the second column as node text field.)

ChildNodeValueField: Name of the field of Child table that has to be set as value. Value field can be used for saving page URL's if required, otherwise it is suitable to save ID's. (Optional, if not set, XtreeView takes the first column as node text field.)

ChildParentRelationField:  Name of the field (foreign key) of the child table that is being used as primary key in parent table. (Mandatory)

ChildGrandChildRelationField:  Name of the field (primary key) of this immediate parent table that is being used as foreign key in grand child table. (Mandatory, if there is, it is child)

Grand Child has the following properties.

GrandChildTableName:  Name of the Grand Child table.  (Mandatory)

GrandChildNodeTextField: Name of the field of Grand Child table to be displayed as the node text. (Optional, if not set, XtreeView takes the second column as node text field.)

GrandChildNodeValueField: Name of the field of Grand Child table that has to be set as the value. Value field can be used for saving page URL's if required, otherwise it is suitable to save ID's. (Optional, if not set, XtreeView takes the first column as node text field.)

GrandChildChildRelationField:  Name of the field (foreign key) in the grand child table that is being used as primary key in immediate parent table. (Mandatory)

You may have noticed that most of the properties are optiona;l if you do not set them, they are set with default fields.  For binding XTreeView with relational database we need the following information:

Name of table(s)

Name of the relation field(s) with (immediate) parent and (immediate) child, a primary key field in case of parent table and foreign key field in case of child table.

A real world example

Let us take a real world example to use XTreeView. Here, I have the database of Pakistan’s cities. There are three tables in it. They are related with each other with parent child relationship. The following figure shows this.

Figure 5

In Pakistan we have Provinces, a province can have multiple regional Divisions and a division can have multiple Districts. Hence, as shown in the above diagram, we have Provinces as parent table, Divisions as child table that has ProvinceID as foreign key, and Districts as the grand child table having DivisionID as the foreign key. Now let us see how we can bind this database with XtreeView. First, drag XTreeView control and drop on the page and set the aforementioned properties. The following listing shows this.

Listing 5

<cc1:XTreeView ID="XTreeView1"
 ConnectionString="Data Source=gmohyd-serv;Initial Catalog=pakistan_db;Integrated Security=True"  
GrandChildRelationField="DivisionID" >

The properties in bold are mandatory. If you do not set other properties, even then it works fine. By default, it takes the first field as the value field and the second field as the text field. If you have tables with this design then you do not need to set all properties, go for only the mandatory ones.

You might have noticed that in Child part of properties we have two properties for the relation fields. Since it is mandatory to relate the child with its parent and its grand child, we require ChildParentRelationField  and ChildGrandChildRelationField for its relation with parent and grand child,respectively.  

Hence it accomplishes binding XTreeView with database. Here is the output when viewed in the browser.

Figure 6

Binding with Dataset Programmatically

There may be the situations when it would be required to bind the XTreeView programmatically. Sometimes it becomes necessary to have more control on what an extended control does implicitly. XTreeView has property DataSet that is to be set programmatically after populating it with tables and setting its relations. The following code listing shows this.

Listing 6

SqlConnection dbCon = new
 SqlConnection("Data Source=gmohyd-serv;Initial
 Catalog=pakistan_db;Integrated Security=True");
DataSet ds = new DataSet();
SqlDataAdapter adapter = new SqlDataAdapter("SELECT * FROM Provinces", dbCon);
DataTable parentTable = new DataTable("Provinces ");
adapter = new SqlDataAdapter("SELECT * FROM Divisions", dbCon);
DataTable childTable = new DataTable("Divisions");
adapter = new SqlDataAdapter("SELECT * FROM Districts", dbCon);
DataTable gchildTable = new DataTable("Districts ");

Binding XTreeView is no longer a difficult job to do now. First, you have to take a connection object and open it. Then take a DataSet object and initialize it. Take SQLDataAdapter object and fill the parent table through it. Do not forget to name the table while initializing the DataTable object because it will be used implicitly by the table name property of XTreeView. Then add it to the table collection of the dataset. Repeat the same steps for each next child table. In our case we have three tables, Provinces, Division and Districts. Though populating the dataset with the tables has been accomplished, we are still left with setting the fields’ mandatory relationship properties of the control.

Listing 7

XTreeView1.ParentChildRealtionField = "ProvinceID";
XTreeView1.ChildParentRelationField = "ProvinceID";
XTreeView1.ChildGrandChildRelationField = "DivisionID";
XTreeView1.GrandChildRelationField = "DivisionID";
XTreeView1.DataSet = ds; 

These properties are self explanatory and also have been explained earlier. The important point here is that even programmatically, much of the effort of binding and establishing relationship between tables has been lifted through these properties. You can still use the table text field and table value filed properties which are optional, otherwise default will be used. You can set the table value field property with the field name that contains the corresponding pages path if any (only from root directory or sub folders). In this way, you can take advantage of navigation using database or side-by-side with sitemap. Lastly, you have to set the DataSet property of XTreeView with the populated dataset.


Lastly, I would like to acknowledge Andrew Robinson’s work for saving TreeView state (available on his blog). This control has benefited from it.


Extended TreeView is of great use when we want to save expansion state and bind it with multiple sitemaps. It can also minimize the effort of writing code for binding a TreeView with database programmatically. It gives us flexibility to have more than one sitemaps in application and bind each of them with a separate instance of XTreeView. It helps us organize site maps into categories and apply, if required, different layout and appearance to each of them.

Although I have tried to provide maximum ease of use and flexibility in this version of Extended TreeView, there is one limitation - binding XTreeView with a database. We can only bind it to three levels, as most of time we need up to three levels. Making it bindable up to n levels would have created complexity. That requires extensibility on TreeNode level. But the properties that work for binding XTreeView with database have been intentionally provided at TreeView level, instead of TreeNode just for sake of simplicity and ease of use, therefore extensibility got compromised. That might be incorporated in some future version of the control. Even in case one requires binding it with more than three levels, he or she can still go for it and can take the advantage of expansion state saving feature (in this case it can be binded with database programmatically, the traditional way). I hope it will work great. Use it and have fun.

Happy TreeViewing!

Product Spotlight
Product Spotlight 

©Copyright 1998-2020  |  Page Processed at 2020-01-26 3:24:01 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search