Keep Row In Place When Loading Data

[Scott]

I'm using the RadTreeListView for hierarchal data.  When the user expands a row, I call a WCF service to populate the next level.  The control always scrolls to the top when doing this which is really annoying.  I have also tried to ScrollIntoView() method, but it scrolls the row to the bottom of the visible window.  What I want to do is keep the row in place so the user is not searching for the data they just expanded.

Is there an easy way to keep the row in the same location when expanding the parent row?  If not, is there a way to get the current index within the visible window so I can calculate which row to set in the ScrollIntoView() method to get the same affect?

Someone must have found a way to do this.  In my opinion, having the row the user just clicked on disappear is a bad design.  The user is expecting the parent row to still be under the mouse cursor after the click.

Any help would be appreciated.

-Scott

[Vlad]

Hi,

 I'm not sure why the treelist is scrolling to top - we don't have such problem on our demo. Can you send us an example demonstrating this? 

Kind regards,
Vlad
the Telerik team

[Scott]

I found what was causing the issue and have found a suitable work-around.  My TreeListView has a Parent level.  Each parent can have any number of children (only going two levels deep).  When Initially loading the TreeListView, I check to see if the parent should indicate that it has any children.  If it does, I load ONLY the first child.  This allows the TreeListView to show the arrow indicating there are children available.  Then, when the parent node is expanded I load the rest of the children (kindof lazy loading).  Here is where the scrolling happens.  When retrieving the children from the WCF service, I was clearing the ObservableCollection holding the one child, then filling it again with all the results from the service call.  This forces the entire control to scroll to the top.

My work-around simply adds the children to the ObservableCollection starting with the second child (since it is already there).  Because I am no longer clearing the child's ObservableCollection, the control behaves correctly.

I hope this helps...

-Scott