One list of multiple lists doesn't really matter.
gbenshim said:Does the problem that you're describing here origin is because depth level of each row is different?
Yes, that's the basic issue. The BindingManager will attempt to retrive the data schema from the active row. This is typically the first row. So if your first row's list doesn't return any child rows and the BindingManager is unable to add one and cancel it, then it won't be able to get the schema for the child bands and this will cause problems for other rows that DO have child rows.
As long as the first row either has child rows going down the chain to the maximum depth, or you have implement IEditableObject so that the BindingManager can create and cancel such rows, it will work okay.
Okay, let's take your example and say you have two types: A and B.
A has certain properties and so does B.
If I understand you correctly, then type A will have among it's properties two properties that return BindingLists: one which returns a list of type A object and another which returns a list of type B objects.
Type B has among it's properties the same two lists: a list of As and a list of Bs.
To be perfectly honest, I'm not sure if what you describe here will work or not.
Let's say you bind the grid to a list of objects of type A. By default, the grid will load all of the root-level rows. It will not load any child rows until you expand a parent row. But... the grid WILL attempt to get the schema of the child rows initially. The grid gets this information from the BindingManager. I think the BindingManager will not have any trouble getting the first level of child rows, sincethe "A" object will return a couple of properties that are lists of specific types A and B.
But once you go down beyond that level, there might be problem because the first root-level row will not have any child rows. Therefore, the BindingManager may not be able to get the schema of the grandchild rows. The only way to know for sure would be to test this out.
If it does not work in the grid, it will almost certainly work in the tree, because the tree gets the data schema lazily instead of trying to get it all at once at the time of binding. You can also probably make it work in the grid by implementing IEditableObject which will allow the BindingManager to create and cancel some extra rows.
So I beleive it should be possible to acheive what you want, it just might require a little extra coding on your part.
gbenshim said:each root item has children from different kind
I'm not entirely clear on what you mean by this. If you mean that each parent row has child rows with different columns, then the answer to your first question is no, the grid cannot handle this. The grid can only deal with a homogeneous data source where all rows in the same band have the same column structure.
If you have a limited number of types of child bands, then perhaps you could add bands for all of them and then simply have no rows where none are needed. But that's a design decision and depends on how many different job schemas you have and what your priorities are.
The tree can handle non-homogenous data sources. But as you know, it does not have filtering or summaries. The tree does have sorting, though.
gbenshim said:2. Is it possible to create a scheme that will bind to create this automatically without having to manually build this tree with code?
I beleive the tree will pick this up automatically, providing that every node in the same collection (not neccessarily the same band, but the same island) has the same schema.
gbenshim said:3. Where can I find references/help on how to do this
There are samples of binding the tree as well as documentation in the help regarding Columns and ColumnSets. It's hard to give you any more specifics without more specific questions. But if you simply set up your data source with the structure you want, it sounds to me like the tree will pick iy up automatically.