I have a proof-of-concept WPF app with parent RadGridView with two hierarchical levels of child details. Most of the information on the child detail of the top-level parent is in a child RadGridView. That child grid's row details are mainly another RadGridView of the first child's children. In the POC, all three grids were bound directly to VS2010-generated DataAdapters/Views. That worked fine as long as only one top-level parent at a time had to display row details.
Now I find I need to instead have row details displayed at the same time for multiple parent rows in a RadGridView. But if I simply source the child details out of the existing child dataset, then all parent table rows will show the child details for the same, currently selected parent row instead of being the unique child details which match each parent row.
I'd like to know what you recommend as the best practice for providing binding sources for child table-sourced row details to support multiple, simultaneous child row details displays.
I had thought about creating separate observable collections in the LoadingRowDetails event of the top two grids. But with the parent grids' rows directly bound to DataAdapters/DataViews, there is no way to separate the data contexts with multiple top-level parent row details simultaneously opened.
I realize could do this by hand-creating three levels of custom business objects and sourcing their content from the database rows. But I'd rather not start over like that if there is a decent solution leveraging at least part of the existing direct database data objects. (All the current code for updating the database is directly using the bound DataSet/DataAdapter objects to automatically track the change deltas and perform the database updates).
What is the best practice here for providing multi-level row-details? Should I just bite the bullet and change the app over to working off of three-level, hierarchical custom business objects, tracking my own change deltas, and hand-coding the database update logic?
Thanks for your thoughts,
-Bob
Now I find I need to instead have row details displayed at the same time for multiple parent rows in a RadGridView. But if I simply source the child details out of the existing child dataset, then all parent table rows will show the child details for the same, currently selected parent row instead of being the unique child details which match each parent row.
I'd like to know what you recommend as the best practice for providing binding sources for child table-sourced row details to support multiple, simultaneous child row details displays.
I had thought about creating separate observable collections in the LoadingRowDetails event of the top two grids. But with the parent grids' rows directly bound to DataAdapters/DataViews, there is no way to separate the data contexts with multiple top-level parent row details simultaneously opened.
I realize could do this by hand-creating three levels of custom business objects and sourcing their content from the database rows. But I'd rather not start over like that if there is a decent solution leveraging at least part of the existing direct database data objects. (All the current code for updating the database is directly using the bound DataSet/DataAdapter objects to automatically track the change deltas and perform the database updates).
What is the best practice here for providing multi-level row-details? Should I just bite the bullet and change the app over to working off of three-level, hierarchical custom business objects, tracking my own change deltas, and hand-coding the database update logic?
Thanks for your thoughts,
-Bob