View previous topic :: View next topic |
Author |
Message |
MHB
Joined: 04 Apr 2005 Posts: 69
|
Posted: Tue Aug 23, 2005 2:35 pm Post subject: ExpandRow event |
|
|
It would give some flexibility to have an ExpandRow event and a matching OnExpandRow method (or equivalent) on VirtualTree, which would be called (surprise) just before a row is expanded.
For me, this would enable batch fetching all the grandchild lists at once, instead of having to request them one at a time (I'm transmitting the data over the Internet, so all the round trips make a big difference). The grandchild lists are fetched in order to determine whether the children are expandable and hence should have an expand icon next to them. |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Tue Aug 23, 2005 11:22 pm Post subject: |
|
|
We will add this to our feature request list. _________________ Infralution Support |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Fri Sep 30, 2005 10:33 am Post subject: |
|
|
This has now been added in Version 2.1.0 _________________ Infralution Support |
|
Back to top |
|
|
MHB
Joined: 04 Apr 2005 Posts: 69
|
Posted: Tue Oct 11, 2005 5:21 pm Post subject: |
|
|
Cool! We are making some progress here
Now if only I had some way of telling VirtualTree whether a row is expandable without looking for children, I could defer fetching the actual children until they are really needed for displaying... Before that, I would only need to transmit a list of bools indicating which children give rise to grandchildren.
Would this be complicated? Or am I overlooking an existing method of doing this? I could produce some bogus object to put in child lists, and then check for this bogus object when the children are really needed, but I would need some child/expand update logic, and the solution seems a bit messy... How about a nice bool object property that, when set, overrides the use of child lists to determine expandability? |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Tue Oct 11, 2005 10:48 pm Post subject: |
|
|
MHB wrote: | Now if only I had some way of telling VirtualTree whether a row is expandable without looking for children, I could defer fetching the actual children until they are really needed for displaying... Before that, I would only need to transmit a list of bools indicating which children give rise to grandchildren.
|
OK you've lost me here. If you don't want a row to be expandable simply return null in the GetChildren event/GetChildrenForRow method. If you want to defer loading of the children until the user actually attempts to expand the row then you can use the ChildPolicy.LoadOnExpand option. _________________ Infralution Support |
|
Back to top |
|
|
MHB
Joined: 04 Apr 2005 Posts: 69
|
Posted: Wed Oct 12, 2005 10:50 am Post subject: |
|
|
Sorry My point was that when using LoadOnExpand, the 'plus' expansion indicator is shown regardless of whether the row actually has any children. It's really nice to only have the plus next to rows that actually have children, but currently that's only possible by loading the children (RowChildPolicy.Normal). The LoadOnExpand is so annoying that I almost forgot it exists
Bottom line: I still want the row to be expandable, and I still only want to show the plus if the row really has children (ie. LoadOnExpand is not an option), but I would like to defer loading the children themselves until the row is expanded. This could be obtained by having a property ('ExpandableProperty') on my object used for ObjectRowBinding. This property would then be used to determine whether a plus should be displayed or not. Maybe what I'm asking for is a new RowChildPolicy.UseExpandableProperty?
I hope that clears it up a bit |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Wed Oct 12, 2005 10:49 pm Post subject: |
|
|
To check if a particular row has children would require a server round trip - correct? So in terms of server round trips just getting the children instead won't take any more round trips - in fact it will save you another round trip if the user then expands the row. Unless the number of children is very large this will be a more efficient algorithm - because server round trip time (network latency) is typically much larger then time required to retrieve data from the local disk.
If you do have a very large number of children then you should be looking at strategies to page the data from the server. To do this you would create a collection that implements IList and retrieves the data from the server in chunks as the user accesses the data via the IList.Item(index) method. If you implement a paged collection with an initial page size of zero then you will actually get what you are requesting. ie the first server round trip will retrieve the Count of the list - but no items. Then if the client accesses an item the first page of items will be retrieved.
We have been considering developing some support classes to help customers implement paged collections for this type of scenario. _________________ Infralution Support |
|
Back to top |
|
|
MHB
Joined: 04 Apr 2005 Posts: 69
|
Posted: Thu Oct 13, 2005 12:34 pm Post subject: |
|
|
I'm well aware that the rtt is usually the dominant part of delay on an internet connection. That's exactly why I wanted OnRowExpand, to enable batching of data! My idea was something like this: OnRowExpand fetches information for all children of the expanded row in one round trip. This information includes everything needed to display each child. That in turn includes whether the expansion indicator should be shown. Currently, I would need all the grandchildren, and this is where a large optimization could be made if this was reduced to a bool.
I can see now that this could be obtained by using some form of paged collection. Then I could transmit counts instead of bools, and use these to initialize the collections of all the children (without the need for separate round trips). I hadn't though of this approach, which has the advantage of also speeding up the display of large child lists. This was your primary reason, but that's not so important in my case. My main concern is minimizing the amount of tree nodes being transmitted, since each node contains rather a lot of data, and hence it's a large (noticeable) overhead to have to transmit all of the (never displayed) children of displayed nodes, just to determine whether an expansion indicator should be displayed.
I will consider expanding my child list class with paging functionality... |
|
Back to top |
|
|
|