View previous topic :: View next topic |
Author |
Message |
MHB
Joined: 04 Apr 2005 Posts: 69
|
Posted: Mon Apr 04, 2005 3:45 pm Post subject: UpdateRows() without collapsing tree |
|
|
It would be a lot more user friendly if UpdateRows() didn't collapse the entire tree, but kept the view exactly as it was, except that changes in the data source would be reflected.
I try to use UpdateRowData instead, but that doesn't catch new and deleted children. |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Tue Apr 05, 2005 8:23 am Post subject: |
|
|
Actually this is the behaviour of UpdateRows() if you don't generate new lists of objects each time GetChildren. You can check this by modifying the ADO Dataset sample to call UpdateRows() - the current tree expansion state is unaffected.
The UpdateRows() method simply calls RootRow.UpdateChildren(reloadChildren =>true, recursive => true). Which means that the tree will cause the lists of children to be reloaded. If instead you call RootRow.UpdateChildren(false, true) you will probably get the behaviour you want. _________________ Infralution Support |
|
Back to top |
|
|
MHB
Joined: 04 Apr 2005 Posts: 69
|
Posted: Wed Apr 06, 2005 2:39 pm Post subject: |
|
|
Quote: | this is the behaviour of UpdateRows() if you don't generate new lists of objects each time GetChildren |
That was a nice piece of information, it should be in the description of UpdateChildren, UpdateRows and/or GetChildrenForRow! I generated new lists on every call. I have now changed this behaviour, resulting in a few complications, but it works...
UpdateChildren(reloadChildren = false, recursive = true) did not solve the problem. In fact it seems like only leaf nodes are reloaded. I don't quite see how reloadChildren = false should be useful? |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Wed Apr 06, 2005 11:50 pm Post subject: |
|
|
If the actual list object you return in GetChildrenForRow doesn't change (ie you maintain a reference to this list in your own code) then you could add an item to the list of children and then call UpdateChildren(false, true) on the parent row.
VirtualTree then does not have to call GetChildrenForRow again to reload the list of children (because the list reference is unchanged). It simply updates the visual representation of the rows children to match the new size and contents of the current list.
Typically in this paradigm GetChildrenForRow would create new lists and their contents (for example loading objects from a database) and you use UpdateChildren(false, true) to force the tree to update the visual representation when you add/delete something to one of the lists.
If you have a large project then I would also recommend investigating using lists that support IBindingList as this means you don't have to hand code the update stuff at all - it all happens automatically. We provide a base class (BindingCollectionBase) that makes implementing binding collections very easy. _________________ Infralution Support |
|
Back to top |
|
|
MHB
Joined: 04 Apr 2005 Posts: 69
|
Posted: Fri Apr 08, 2005 11:18 am Post subject: |
|
|
Thanks - good explanation! Now I think I understand what's going on. These descriptions belong in the help files, so others may find them more easily! |
|
Back to top |
|
|
|