Chapter 16. TreeView and ListView
| The TreeView control displays hierarchical data. Perhaps the most prominent tree view of all time is the left side of Windows Explorer, where all the user's disk drives and directories are displayed. A tree view also shows up in the left side of the Microsoft Document Viewer used to display Microsoft Visual Studio and .NET documentation. The tree view in the Document Viewer shows all the .NET namespaces, followed by nested classes and structures, and then methods and properties, among other information. Each item on the Windows Presentation Foundation TreeView control is an object of type TreeViewItem. A TreeViewItem is usually identified by a short text string but also contains a collection of nested TreeViewItem objects. In this way, TreeView is very similar to Menu, and TreeViewItem is very similar to MenuItem, as you can see from the following selected class hierarchy showing all major controls covered in the previous two chapters: Control As you'll recall, ItemsControl is also the parent class of Selector, which is the parent class of ListBox and ComboBox. ItemsControl contains an important property named Items, which is a collection of the items that appear listed in the control. To ItemsControl the HeaderedItemsControl adds a property named Header. Although this Header property is of type Object, very often it's just a text string. Just as Menu is a collection of the top-level MenuItem objectsand hence has no Header property itselfTreeView is a collection of top-level TreeViewItem objects and also has no Header property. The following program populates a TreeView control "manually"that is, with explicit hard-coded items.
The program shows two different ways to add TreeViewItem objects to a parent item. You can explicitly create an object of type TreeViewItem and add that to the ItemCollection object referenced by the Items property. This approach is necessary if the item has child items. However, if the item has no children, a much simpler approach is to pass a text string to the Add method of the Items collection. You'll even notice that one of the items (for the type of cat known as Noodles) is actually a Button control because Noodles is, well, a very special cat. This program gives you an opportunity to explore the user interface of TreeView. You can click a plus sign to expand an item and click the minus sign to collapse it. The TreeView also has a complete keyboard interface based around the arrow keys. Other than that, the program doesn't show any useful generalized techniques for programming the TreeView. Although it's common to populate a Menu control by manually adding items and subitems, populating a TreeView control in this way is probably quite rare in real-life applications. It's much more common to populate a TreeView control based on some database or other information external to the program. For example, a TreeView control that displays disk drives and directories uses classes from the System.IO namespace to populate the TreeView. Here's a program that assembles a TreeView control showing all the directories on the current system drive. (The system drive is usually drive C, of course, but if a drive has multiple bootable partitions, the system drive could be something else.) Let the name of this program be a warning to you: This program shows the wrong way to populate a TreeView with a directory tree!
In theory, the program looks fine. The window constructor creates the TreeView control and creates the first TreeViewItem. This item's Header property is assigned the path root of the current system drive (for example, a text string like "C:\") and the Tag property gets a DirectoryInfo object based on that same string. The constructor then passes this TreeViewItem object to GetSubdirectories. GetSubdirectories is a recursive method. It uses the GetDirectories method of DirectoryInfo to obtain all the child subdirectories. (A try-catch block is necessary in case it encounters a directory where access is forbidden.) For each subdirectory, the method creates a new TreeViewItem object and then calls GetSubdirectories with that new item. Structurally, this is precisely the way we once wrote command-line utilities to display directory trees. Of course, what's fine for the command line is terrible for a graphical environment. If you dare to run this program, you'll discover that it spends a long time grinding through the disk before displaying the window. Not only is the time delay a problem, but the program is doing much more than it needs to. It's highly unlikely the user needs to see every single directory the program is adding to the TreeView. The program may even be exercising parts of the hard drive that haven't been touched since the machine left the factory! A much better TreeView for displaying a directory tree obtains subdirectories only when they're requiredfor example, when the user clicks the plus sign next to a directory. Actually, that's a little too late. The plus sign is displayed only if the item has child items, so the program has to be one step ahead of the user. For each item that is displayed, the subitems need to be present, but the sub-subitems don't need to be immediately included. When you delay loading data, such as I've described, you're using a technique known as "lazy loading." To do TreeView lazy loading properly, you need to be familiar with TreeViewItem events, of which there are four. The Expanded event signals when a user clicks a plus sign to display child items, or when a program manually sets the IsExpanded property to true. The Collapse event signals the opposite: Child items are being hidden. The Selected and Unselected events indicate that an item is being selected by the user or the IsSelected property has changed. All four events have accompanying On methods. In addition, the TreeView itself has a SelectedItemChanged event. However, the SelectedItem property of TreeView is read-only, so if you want to programmatically set an initial selected item in a TreeView, set the IsSelected property of the actual TreeViewItem. Let's see if we can use these events to implement a directory TreeView that actually works well. To make this exercise even more fun, let's display a list of files when a directory is selected. And to make it even more fun than that, let's use little bitmaps in the TreeView. These bitmaps, obtained from the outline\16color_nomask directory of the Visual Studio image library, require a white background. I modified some of them to make the device resolution 96 DPI. The images I used are 35Floppy.bmp, Cddrive.bmp, Clsdfold.bmp ("closed folder"), Drive.bmp, and Openfold.bmp. As in Windows Explorer, the folder image changes from closed to open when a directory is selected. In a nod towards reusability, this project begins with a class that inherits from TreeViewItem called ImagedTreeViewItem.
The ImagedTreeViewItem class sets the Header property it inherits from TreeViewItem to a StackPanel. The StackPanel children are an Image object and a TextBlock. A public property named Text lets a consumer of this control set the Text property of the TextBlock. The two other public properties are both of type ImageSource and are named SelectedImagethe image that is to appear when the item is selectedand UnselectedImage, the image that appears otherwise. Overrides of the OnSelected and OnUnselected methods are responsible for setting the Source property of the Image object to the proper ImageSource. The DirectoryTreeViewItem class inherits from ImagedTreeViewItem and supplies the two images that its base class requires. The constructor of this class has a DirectoryInfo parameter that it saves as a field and exposes through its public DirectoryInfo property. (Another way to think about this is that DirectoryTreeViewItem is a visual wrapper around a DirectoryInfo object.) Notice that the constructor also sets the Text property that ImagedTreeViewItem defines.
The public Populate method obtains all the subdirectories of the DirectoryInfo object associated with the item, and creates new DirectoryTreeViewItem objects that are children of this item. Originally, I defined Populate as a private method that was called from the constructor. You'll see shortly why I had to make it public and not called by default. The class also overrides the OnExpanded method. The OnExpanded method essentially brings into view all the child subdirectories. At this time, all these child subdirectories need to be populated with their own subdirectories so that they properly display plus signs (or not). That's the job of the OnExpanded method. The DirectoryTreeView class derives from TreeView. This is the class responsible for obtaining all the disk drives and beginning the process of creating DirectoryTreeViewItem objects.
Although not used in this project, I gave DirectoryTreeView a public RefreshTree method. This might be called from a Refresh menu item. Here it's just called from the constructor. The RefreshTree method goes into an initialization block by calling BeginInit, deletes all its items, and recreates them. After BeginInit is called, the TreeView won't attempt to keep itself visually updated because that could slow down the construction of the tree. The RefreshTree method obtains an array of DriveInfo objects describing all the drives on the machine. The RootDirectory property of DriveInfo is an object of type DirectoryInfo, so it's easy to create a DirectoryTreeViewItem from it. However, the A and B drives have to be handled with kid gloves. The next-to-last thing you want when initializing a TreeView control is for a floppy disk drive to start spinning. The very last thing you want is for a message box to pop up complaining that there's no disk in the drive! That's why this code doesn't touch the IsReady property of DriveInfo for floppy drives. Also, notice that the method calls Populate for the drive only if the drive is not a floppy disk and the IsReady property is true. The final class in the RecurseDirectoriesIncrementally project is a class with that name that inherits from Window.
The constructor creates a Grid with three columnsone for the DirectoryTreeView, one for the GridSplitter, and the third for a ScrollViewer that contains a StackPanel. This is where files are displayed. The constructor sets an event handler for the SelectedItemChanged event and processes that event by clearing all child elements from the StackPanel and then filling it up again with all the files in the selected directory. Of course, you can't do anything with these files, but you're well on your way to writing a clone of Windows Explorer. You might recall the ItemTemplate property of ListBox. In Chapter 13, "ListBox Selection," I showed you how to define a DataTemplate object that you can set to the ItemTemplate property. This DataTemplate includes a VisualTree that describes how items are to be visually represented in the ListBox. That ItemTemplate property is defined by ItemsControl, so it's inherited by TreeView. Moreover, a class named HierarchicalDataTemplate derives from DataTemplate, and this class is ideal for describing hierarchical data from which a TreeView is built. To use this facility, you'll want to begin by defining a class that describes the hierarchical data you want the TreeView to display. Here is such a class, named DiskDirectory, that is basically a wrapper around a DirectoryInfo object. In fact, if DirectoryInfo were not sealed, I would have derived DiskDirectory from DirectoryInfo and the class would have been simplified a bit. I wouldn't have needed the constructor or the Name property, for example.
The crucial property here is Subdirectories, which basically calls GetDirectories and then creates a DiskDirectory object for each subdirectory and adds that to a List collection. This List object is what it returns from the property. The TemplateTheTree program makes use of the DiskDirectory class in defining a data template for a TreeView.
The HierarchicalDataTemplate object created here is based on the DiskDirectory class. This template will be associated with a TreeViewItem object, which essentially displays a DiskDirectory object. HierarchicalDataTemplate has an ItemsSource property for the source of its Items collection. This is the Subdirectories property of DiskDirectory. The next step is to build a visual tree based on FrameworkElementFactory objects. To keep this example simple, the visual tree for the TreeViewItem is merely a TextBlock. The Text property of this TextBlock is bound with the Name property from DiskDirectory. The constructor continues by creating an object of type DiskDirectory for the system drive. (Again, I'm keeping the example simple by not getting all the drives.) A single TreeViewItem is created with its Header property set to the Name property of the DiskDirectory object, its ItemsSource property set to the Subdirectories property of the DiskDirectory object, and its ItemTemplate property set to the HierarchicalDataTemplate we've just created. Thus, children of this root TreeViewItem will be based on the Subdirectories property of the created DiskDirectory object, but these children will be displayed using the HierarchicalDataTemplate, and this template describes where all future items come from and how they are displayed. The TreeView displays a directory tree efficiently with no event handler. Although this program shows how to use this technique when every TreeViewItem is the same sort of object, it's also possible to use it with tree views where parent and child items may be different types. I show more template examples in Chapter 25. The final TreeView example in this chapter uses the control to display all the Windows Presentation Foundation public classes that descend from DispatcherObject. The TreeView is ideal for this job because the items can be shown in a visual hierarchy that parallels the inheritance hierarchy. Although the program displays names of classes, let's make the code somewhat generalized by writing a class that displays the name associated with any Type object. The TypeTreeViewItem class inherits from TreeViewItem and includes a property named Type. Of course, the type of the Type property is Type.
The program has two constructors to let you set the Type property when creating the object or later. Notice that the set accessor of the Type property sets the Header property of the TreeViewItem to the Name property of the Type object, possibly with the word abstract in parentheses. For example, you could create an object of TypeTreeViewItem and set the Type property like this: TypeTreeViewItem item = new TypeTreeViewItem(); item.Type = typeof(Button); The item displays the simple text "Button", but the actual Type object associated with this item would still be available from the Type property. (The set accessor of the Type property could have set Header to the Type object itself, but in that case the Type object would have been displayed using the ToString method of the Type class, and ToString returns the fullyqualified namefor example, "System.Windows.Controls.Button".) The next step in creating this program is defining a class named ClassHierarchyTreeView that inherits from TreeView.
Everything happens in the constructor of this class. The constructor requires a root Type that begins the hierarchy. It first creates a List object for storing all the AssemblyName objects referenced by the program, and then loads these assemblies to make Assembly objects. The constructor then creates a SortedList object to store the Type objects representing those classes that derive from typeRoot. These Type objects are sorted by the Name property of the type. The constructor simply loops through all the Assembly objects and the Type objects in each assembly searching for these classes. Once all the classes are accumulated in the SortedList, the constructor must create a TypeTreeViewItem for each of these classes. That's the job of the recursive CreateLinkedItems method. The first argument is TypeTreeViewItem associated with a particular class. The method simply loops through all the classes in the SortedList and finds those whose base type is that class. The method creates a new TypeTreeViewItem for each of them and adds it to the collection of the base class. The previous two source code files and the next one are all part of the ShowClassHierarchy project. The constructor sets the window content to an object of type ClassHierarchyTreeView with a root class of DispatcherObject.
You might be tempted to replace the reference to DispatcherObject with typeof(Object) to get an even bigger class hierarchy, but the logic in ClassHierarchyTreeView breaks down when two classes in different namespaces have the same name, which is the case when you begin with Object. If the TreeView control resembles the left side of Windows Explorer, the ListView control comes closest to resembling the right side. In Windows Explorer, you can choose different views: Icons, Tiles, List, Thumbnails, or Details. You've already seen in Chapter 13 how you can define a template for the ListBox and display objects in different formats, so for many displays of objects you can use a ListBox with a custom template. The tough one, however, is the Details view, because that requires multiple columns and column headings. That's where ListView comes to the rescue. The ListView control derives directly from ListBox. (Also, ListViewItem derives directly from ListBoxItem.) Just like ListBox, ListView has a property named Items that stores the objects displayed by the control. ListView also has an ItemsSource property that you can set to an array or other collection of objects. ListView adds just one additional property to ListBox, a property named View of type ViewBase. If View is null, ListView basically functions just like ListBox. Currently only one class derives from ViewBase, and that's GridView, which displays objects in multiple columns with column headings. The crucial property of GridView is Columns, an object of type GridViewColumnCollection. For each column you want displayed, you'll create an object of type GridViewColumn and add it to the Columns collection. The GridViewColumn object indicates the column heading, the column width, and the property of the item you want displayed in that column. For example, suppose you've set the Items collection of your ListView control to objects of type Personnel, a class that has properties named FirstName, LastName, EmailAddress, and so forth. In defining each column of the ListView, you indicate the particular property of Personnel (FirstName, LastName, or whatever) you want displayed in that column. You identify the property with a binding. The first program I want to show you displays all the properties and values from the SystemParameters class. The SystemParameters class has numerous static properties such as MenuBarHeight and IsMouseWheelPresent. These particular properties indicate the default height of the application menu and whether or not the mouse attached to the computer has a mouse wheel. The first step in displaying information in a GridView is to define a class describing the items you want to display. I want two columns in the GridView: the first for the name of the property and the second for the value. The class for storing each item I named SystemParams.
The ListSystemParameters class inherits from Window and creates a ListView control that fills its client area. It then creates a GridView object and sets that to the View property of the ListView.
The first GridViewColumn is for displaying the property names of the SystemParameters class. The Header property is "Property Name" and the Width property is 200 device-independent units. The DisplayMemberBinding property of GridViewColumn must be set to a binding indicating the property of the data to display, in this case a property of SystemParam. This column should display the Name property of SystemParam, so: col.DisplayMemberBinding = new Binding("Name"); Similarly, the second column is given a Header property of "Value" and bound with the Value property of SystemParams. So far, the ListView has no items. The constructor concludes by using reflection to obtain an array of PropertyInfo objects from SystemParameters. For each property, the program creates an object of type SystemParam and assigns the Name property from the Name property of PropertyInfo and the Value property from the GetValue method of PropertyInfo. Each item is added to the Items collection. Notice that the logic skips all properties in SystemParameters of type ResourceKey. Each property in the class exists in two forms. For example, MenuBarHeight is of type double, and MenuBarHeightKey is of type ResourceKey. The properties of type ResourceKey are mostly for use in XAML, as you'll discover in Chapter 21. If you delete the program statement lstvue.View = grdvue; the View property remains at its default null value and the ListView behaves just a ListBox. The items are displayed with strings from the ToString method of SystemParem, which certainly gives you all the information but not very attractively. One problem with the ListSystemParameters program is that the items are not sorted. There are a couple ways to fix that problem. One approach is to sort the PropertyInfo array before the foreach loop. For this job you'll need a small class that implements the IComparer interface and has a Compare method to compare two PropertyInfo items. Here's a simple implementation of such a class: class PropertyInfoCompare : IComparer<PropertyInfo> { public int Compare(PropertyInfo prop1, PropertyInfo prop2) { return string.Compare(prop1.Name, prop2.Name); } } The ListSystemParameters.cs file already includes a using directive for System.Collections.Generic. To sort the PropertyInfo array using the PropertyInfoCompare class, you simply call: Array.Sort(props, new PropertyInfoCompare()); A second approach requires a using directive for the System.ComponentModel namespace (which ListSystemParameters.cs already has). You create a SortDescription object referencing a property of the items you want sorted, and add it to the SortDescriptions collection defined by ItemCollection: lstvue.Items.SortDescriptions.Add( new SortDescription("Name", ListSortDirection.Ascending)); A third approach involves a SortedList collection. This approach is shown in the next version of the program. It defines a SortedList with string objects as keys and SystemParam objects as values: SortedList<string, SystemParam> sortlist = new SortedList<string, SystemParam>(); The program then fills up this SortedList from the PropertyInfo array: foreach (PropertyInfo prop in props) if (prop.PropertyType != typeof(ResourceKey)) { SystemParam sysparam = new SystemParam(); sysparam.Name = prop.Name; sysparam.Value = prop.GetValue(null, null); sortlist.Add(prop.Name, sysparam); } Notice that the property name is also the key name of the SortedList, and hence the item used for sorting. The final step is to just set the Values collection of the SortedList to the ItemsSource property of the ListView: lstvue.ItemsSource = sortlist.Values; The Values property of the SortedList is the collection of sorted SystemParam objects. This second version of the program also corrects a little problem with the second column. Because it's displaying various values, it makes more sense to right-justify the contents. There are no alignment settings on the columns. Instead, a more generalized solution involves templates. This version of the program creates a DataTemplate, initializes it with a visual tree consisting of a right-justified TextBlock, and then sets it to the CellTemplate property of the second GridViewColumn:
Notice that the Text property of the TextBlock is bound to the Value property of SystemParam, so the normal DisplayMemberBinding is no longer allowed. When I was exploring dependency properties for Chapter 8, I wrote a small console program for myself that used reflection to obtain information about the dependency properties that some WPF classes defined. But I wanted something more generalized, and that was the origin of the ClassHierarchyTreeView (described earlier in this chapter) and the DependencyPropertyListView (coming up). The final program in this chapter is named ExploreDependencyProperties and it unites these two controls in a single window separated by a splitter. When you select a class from the ClassHierarchyTreeView, the DependencyPropertyListView shows the dependency properties defined by that class, including the FrameworkMetadata flags, if any. DependencyPropertyListView inherits from ListView and displays a collection of objects of type DependencyProperty. Each column is bound to a particular property of DependencyProperty. For example, the first column is bound to the Name property, and the second to the OwnerType property. But here the problems begin. If you just bind a column in the ListView to the OwnerType property of DependencyProperty, you'll see strings like "System.Windows.Controls.Button." That's hard to read. Instead, I wanted the column to contain just "Button." Fortunately, there's a way to do this. When you define a DataTemplate object for the CellTemplate property of the GridViewColumn object, you also define a Binding that links the property you want to display with the element that displays it. The Binding class defines a property named Converter that can convert this bound data to a desired format. This Converter property is of type IValueConverter, which is an interface with just two methods: Convert and ConvertBack. So, we need a class that implements the IValueConverter interface that converts a Type object (such as System.Windows.Controls.Button) to a string ("Button"), and here it is.
The object to be converted enters the Convert method through the first parameter. In the usage of this class, this object will be of type Type. It's cast to a Type object and then the Name property provides the name without the namespace. In my application, the ConvertBack method is never used, so it can simply return null. This conversion is also good for displaying the PropertyType property of DependencyProperty. As you may recall, DependencyProperty defines a property named DefaultMetadata of type PropertyMetadata. This PropertyMetadata object has some useful information in it, particularly the DefaultValue property. However, many elements define their metadata by using an object of type FrameworkPropertyMetadata, which has the essential properties AffectsMeasure, AffectsArrange, AffectsRender, and others. These metadata properties are often set through a constructor using a FrameworkPropertyMetadataOptions enumeration, and this is what I focused on. I didn't want to devote a whole bunch of columns showing Boolean values of AffectsMeasure, AffectsArrange, and so on. I wanted one column that would show all the FrameworkPropertyMetadataOptions members used to create the metadata in the first place. That's the purpose of this conversion class. The Convert method converts an object of the enumeration type FrameworkPropertyMetadata to an object of type FrameworkPropertyMetadataOptions.
When this converted item is actually displayed, the ToString method defined by the Enum structure formats the enumeration into readable comma-separated members. It's now time to look at DependencyPropertyListView. The class derives from ListView and defines a property named Type, backed by the dependency property TypeProperty. Set the Type property of this ListView and the control displays all the DependencyProperty objects defined by that Type. The OnTypePropertyChanged method is responsible for using reflection to obtain all the DependencyProperty objects and putting them in a SortedList collection that it uses to set the ItemsSource property of ListView.
This class's constructor is mainly responsible for defining all the columns. Some of them are simple, and some involve the two converters I discussed. Finally, the ExploreDependencyProperties class puts it all together. It creates a ClassHierarchyTreeView and a DependencyPropertyListView and puts a GridSplitter in between.
The last two statements of the constructor set a binding between the Type property of the DependencyPropertyListView control and the Type property of the SelectedItem property of ClassHierarchyTreeView. That SelectedItem property is actually an object of type TypeTreeViewItem that conveniently defines a property named Type. The simplicity of this binding justifies all the previous work (almost). |
------------------------------------------------ // ManuallyPopulateTreeView.cs (c) 2006 by Charles 
EAN: 2147483647
Pages: 72
- The Effects of an Enterprise Resource Planning System (ERP) Implementation on Job Characteristics – A Study using the Hackman and Oldham Job Characteristics Model
- Distributed Data Warehouse for Geo-spatial Services
- Data Mining for Business Process Reengineering
- A Hybrid Clustering Technique to Improve Patient Data Quality
- Development of Interactive Web Sites to Enhance Police/Community Relations