![]() ![]() Now, I strive to stay as DRY as the next guy, and I tried to come up with a way to collapse the three templates into one. In fact, the only difference among them is whether the second and third ColumnDefinition have the SharedSizeGroup property or not. You've probably noticed that there's an unfortunate amount of XAML duplication above - each of the three HierarchicalDataTemplates are very nearly identical.Therefore, I'm able to insert the appropriate counter-offset for each level of the tree - and everything lines up beautifully! Having done that, the "Toggle" size group can be used to simulate the width of the actual toggle anywhere it's needed. So what I've done is add a special shared size group with exactly the same width as the toggle (this is what the empty TreeViewItem in the header section of the XAML is for). So if all we did was make each column's cells the same width, things wouldn't actually line up because of this offset showing up in different amounts everywhere: You see, each collection of children is offset to the right by exactly the width of the TreeViewItem's toggle element. The following diagram of the default TreeViewItem layout should help explain what I mean: The "Toggle" shared size group which is used to offset TreeViewItem children to take into account the indent that TreeViewItem parents automatically impose on them.Except that they wouldn't actually line up if it weren't for. In this manner, same-width columns are created for the "Task", "Duration", and "Notes" fields so they all line up properly. In the scenario above, that sharing takes place across the separate Grids of the column headers and each TreeViewItem row of data. (Both available only on WPF for now.) By setting IsSharedSizeScope on a parent element and SharedSizeGroup on some of the column/row definitions of Grids within it, it's possible to "link" the sizes of cells across different Grids. The first is the Grid.IsSharedSizeScope attached DependencyProperty and its partner-in-crime DefinitionBase.SharedSizeGroup. There are two "tricks" I use to get DataGrid-like behavior from a TreeView.Here's how my SimpleTreeGridUX sample looks with some data I made up about the schedule of a fictional developer: But because I'm cheap and a show-off - and occasionally fall victim to a little NIH - I decided to craft a TreeGrid-like experience using only the WPF TreeView control, a couple of Grids, and some XAML. The good news is that a bit of web searching will turn up some third-party TreeGrid options that definitely seem worth evaluating. But you won't - it's just not used frequently enough to have made it to the big leagues yet. So with all this talk about TreeGrid, you might expect to find one in the Silverlight or WPF framework, or perhaps as part of the Silverlight Toolkit or WPF Toolkit. In my experience, DataGrids don't tend to summarize the grouped data like we want - but if you have examples to the contrary, I'd love to see them. Aside: You might wonder if DataGrid's native support for grouping would be useful here. However, a list of people's company and salary might make a good TreeGrid because it's natural to group by job and the aggregated salary information could be informative (either as an average or as a sum). For example, a list of people's name and address would not make a good TreeGrid, because there's no natural grouping that makes sense (you can't combine addresses). Most commonly, you'll see a TreeGrid used when the tabular data can be nicely summarized (or "rolled up") into hierarchical groupings. Sometimes you've got data that's basically tabular in nature, yet also has a hierarchical aspect, and you'd like to leverage that to give people control over the level of detail they're seeing. But you may not know about their hybrid love child, the TreeGrid - and that's what this post is about. You know that a TreeView is good for showing hierarchical data and a DataGrid is good for showing tabular data. We indicate that each node should be a TreeViewItem object, with text ( Header) that just binds to the Person object.If you've done much work with WPF or Silverlight, chances are you already know what a TreeView is and what a DataGrid is.We tell the HierarchicalDataTemplate to use the Children property to traverse the hierarchy.We set the ItemsSource of the TreeView to our top-level property (a list of Person, which contains one person).There are several things to note about this XAML fragment: To wire this hierarchical data source up to a TreeView control, we use a HierarchicalDataTemplate in XAML, as shown below. Public Person(string name, int birth, int? death) (INPCBase is just a class that implements INotifyPropert圜hanged and includes a SetField method). Let’s say that we have a Person object that looks like the following. Below is a very simple example of how you might use a TreeView control to display a set of hierarchical data. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |