I'm binding an UltraTree to a structure like this:
list list object object ...
This works fine. I then rebind the tree to a structure with one less level:
list object object ...
This also works fine. However, if I try binding to the original, three-level structure again, I get a tree containing only a single node (for the second-level list, since the first-level list becomes the implicit tree root).
This seems to be related to some games I'm playing in AfterDataNodesCollectionPopulated. In that event, I'm setting NodeLevelOverrides to use a particular column set for each tree level other than the last one, and I'm setting the last level to use a different column set. If I disable this code, the problem does not occur.
It seems to me as if maybe the tree node creation is not working because the second-level list doesn't have all the properties my column set is looking for, or something like that. Any ideas?
Thanks, Aaron
Hi Aaron,
My guess is that this is caused by the automatic generation of ColumnSets in the tree. By default, the tree automatically builds the ColumnSets based on the data structure and it links up the ColumnSet to each band via the band's Key.
Assuming that you are allowing the tree to auto-generate the ColumnSets and are not creating them yourself, you can probably fix the issue very easily by setting the tree's DataSource to null and clearing the tree.ColumnSettings.ColumnSets collection right before you change the tree's DataSource.
Bad news, and more bad news: first, the auto-generated column sets is a feature of the sample code I posted, but it's not what my real code is doing. The real code is assigning column sets using NodeLevelOverrides and has the same symptom.
Second, your solution doesn't actually solve the problem even in the sample code. Just to confirm, I added these two lines before the (re)assignment of DataSource in the button click handler:
this.ultraTree1.DataSource = null; this.ultraTree1.ColumnSettings.ColumnSets.Clear();
That said, at least with this code in place, the auto-generated case seems to use the proper column set for the group after rebinding; it just doesn't create any nodes beneath the group.
So, bottom line, it looks like there are two separate problems here: first, with auto-generated columns, rebinding the data doesn't regenerate the columns; second, rebinding to a "deeper" data set doesn't (always) generate nodes for the "new" levels.
The first problem isn't an issue for me, and is, as you say, easily fixable by manually clearing the column set. The second problem is a big issue, and I don't have a clue what to do about it.
I'm afraid we've started to get into realms of complexity here that are difficult to deal with in a forum post and I'm a bit lost as to where we are, now.
Can you post a small sample project demonstrating the issue?
If you are manually creating the ColumnSets then you have to make sure you create a chaptered column in the ColumnSet that represents the child band. The auto-generated column sets will do this for you automatically, but if you create your own ColumnSets, you have to do it yourself, just as you have to create the columns for the actual columns of data.
I think I've solved this. Can you tell me exactly under what circumstances the AfterDataNodesCollectionPopulated event occurs? I've been assuming that when I rebind the tree (modify its DataSource member), this event should fire exactly once, after all the nodes have been created. If, however, the event fires after each level of nodes is created or some such, that would explain the behavior I was seeing.
I've been using the depth of the node tree in order to count the number of levels in the tree. Seems obvious, right? Unfortunately, after rebinding the tree, in the AfterDataNodesCollectionPopulated event handler, I don't have as many node levels as I think I'm going to, which causes me to set up my column sets incorrectly. I've rewritten my code so that it instead uses the original data source to count levels, and that seems to work fine, suggesting that some of the nodes haven't been created yet when the event is fired.
I would expect this event to fire for each nodes collection. So it would fire only once for the root-level collection. But for each row in the root-level set of data, there is a collection of child rows under than and the event would fire for each one.
The tree also loads the data lazily. So unless you are doing something to force it, the tree will only load the root level and the next level of data initially. Anything below the first child level will not get loaded until something asks for it.
That would explain the behavior, then. As long as I don't do anything in this event that involves the tree's Nodes collection, everything seems to be fine.