Hello,
My situation is described in the subject. I have an UltraWebGrid (2008.3, CLR 3.5) and a typed dataset with one self-referencing table. The columns and bands get auto-generated, I set the table as the datasource and bind the grid.
The grid does indeed display the data hierarchically, but it also includes all "child" rows on the first level (Band 0). Is there any way other than manually removing the "child" rows from the first band in the InitializeLayout event? This is what I do at the moment to remove them from appearing as parents, but I'm wondering if there isn't some hidden property that makes the grid figure this out on its own.
BTW, the grid is read-only, so I'm not worried about any editing consequences.
Regards, Gorazd
There is no "hidden property" that will remove these rows for you. You'd see a similar result for any other hierarchical, databound ASP.NET controls (or Windows Forms controls, for that matter) bound to the same kind of self-refrerencing data source.
One option I've seen used is to have a single table that represents the "root" data, which contains only those entries that have no other parents, and a second table tthat contains the rest of the data. The "parent" table is related to the child table, and the "child" table is related to itself.
That, sir, is an excellent suggestion! I'm going to try it right away.
In the mean time, there is another thing that irks me. In the previously mentioned table, I have a row that has a depth of 4 (where roots have a depth of 1). I don't see that row in the hierarchy. Is there some default limit of three levels of nesting that I can override or am I missing something obvious again?(Should this question be in a thread of its own because of the pending question answered status?)
Were you able to resolve displaying a grid with 4 level depth. Can you please let me know how you did it.
Thanks in Advance
One extension method later, things work without fiddling with the rows in the OnPreRender event, not the InitalizeLayout event handler as I've mistakenly written earlier. And manipulating the data before binding is more correct than manipulating already bound data anyway. Good call there.
Now just a clarification about the other question (either an answer or a new thread suggestion) and I'm verifying your answer.