I had this working with the Ultratree, but it's stopped working. The dataset is complex w/ multiple relations off the same table. One of them is recursive, and that is what I want to show in the tree. It refuses now to show the recursive relation, where it was showing it before I added other relations. I'm extremely frustrated with this and under a time crunch.
Any help would be appreciated.
What's breaking this are other relations within the dataset--relations to other tables within the dataset. I don't want these relations in the tree, so I've deleted them from the columnsets, but that doesn't make any difference. The other thing is if I set ShowBandNodes to "always" it'll show the recursed nodes with separator bands, which I don't want because it adds unnecessary levels to the tree.
Hi Jeff,
The ColumnSets in the tree are very powerful and give you a lot of control, but they can be a little tricky to work with.
The ColumnSets are associated with bands of data via the Key of the ColumnSet. The tree tries to match up the key of the ColumnSet with the name of the band. So if your bands don't all have names, then an empty string might be getting matched up to multiple bands.
It's impossible to say exactly what the problem is without knowing more, but when I debug something like this, I start by handling the ColumnSetGenerated event and looking at the ColumnSet and columns that are being generated. In a recursive situation, you will probably only need one or two column sets and that column set needs to have a column which represents the child band - this column will have the IsChaptered prpoerty set to true. Make sure you don't remove this column or change IsChaptered to false, since that will remove/hide the child band.
If you can duplicate the behavior in a small sample project and submit it to Infragistics Developer Support, they should be able to see what's going on and why the child data isn't showing up.
http://devcenter.infragistics.com/Protected/SubmitSupportIssue.Aspx
I will have to get back to you on this after the new year. I will attempt to work up a "simple" test, but I suspect the complexity of the dataset is integral to the problem, which I am now convinced is a bug within the wintree control because it will display the recursion correctly if I delete relations (not needed for the tree) from the dataset.
Okay, here's a simple way to test what I'm seeing. Create a dataset with two tables. They are exactly the same table--one holds root rows, the other holds all rows with the root-row table having a parent-child relation with the all-rows table; and the all-rows table has a recursive relationship with itself. Hence, you need an id (primary key) and a "parent" column recursing back to id. (The two-table setup eliminates child rows appearing at the root-level in the tree.) Set a binding source pointing at the root table and an ultratree that uses the binding source. The ultratree can autogen the columnsets and it should work great.
Now, add another table to the dataset that has a foreign-key relation to the all-rows table. This table isn't necessary for the ultratree, nor is it wanted in the tree--this table is to be used elsewhere in the app. Don't allow the ultratree to regenerate the columnsets... at this point, I turn the "isautogenerated" off so that it stops asking because I don't want peripheral changes to the dataset causing the ultratree to prompt me CONTINUOUSLY. At this point, the new relation in the dataset breaks the recursion of the all-rows table in the ultratree. You can tell without even running the app because the samples no longer expand past the first child relation (between the root table and the all-rows table). Delete the relation (not even the table) and it works/expands recursively again.
Make sure you have the latest Hot Fix of the control. I think there was a similar issue that might have already been fixed.
If that does not help, you should submit this issue to Infragistics Developer Support. Include a small sample project demonstrating the problem, if you can. Submit a Support Issue
Well, I guess I'll have to go that route since the hotfix... didn't.