Live sorting/grouping

[StackOverflowed]

Does the GridView support live sort and/or live grouping?

By that I mean that if I'm sorting by a column, and one of the values gets updated in the underlying collection, the grid will resort and place that item correctly according to the sort. In other words, if I have a person class (assume INotifyPropertyChanged is implemented correctly, for the sake of brevity):

class Person : INotifyPropertyChanged{
    public int Age{get;set;}
    public string Name {get;set;}
}

and I have an ObservableCollection<Person> that the grid's ItemsSource is bound to, and let's say the grid looks like so:

| Name | Age |
 Tom     12
  Mark   18
  Sam    25

and Sam's age changes to 1 (a data update that happens outside of the grid), I would expect it to become the first row. Currently it does not.

The same question applies to grouping (supporting live updates).

Thanks.

[Vlad]

Hi,

 Please check my last blog post for more info.

All the best,
Vlad
the Telerik team

[Peter]

So your blog post refers to throwing a NotifyCollectionChangedAction.Replace event from the collection the grid is bound to..

That would imply that the row is completely changed out at the collection level.  

In the original question though (I have the same need) the object in that row would presumably throw a NotifyPropertyChanged("Age") which the observableCollections wouldn't turn into a row-replace..  As well, that's just wrong and again wasteful if the row had 200 columns for example, all updating randomly when only maybe 3 were involved in a multi-column sort.  

Shouldn't the grid internally realize that the NotifyPropertyChanged event happened on a column involved in sorting, and trigger the re-sort logic internally?  

We need that functionality, and we're currently at a loss for how to make it work.

-Peter

[Vlad]

Hi,

 RadGridView will reapply grouping, sorting, filtering, aggregates, etc. only if a collection bound to the grid is changed. Reapplying all these on a property change will lead to huge memory and performance problems!

Regards,
Vlad
the Telerik team

[Peter]

Sorry Vlad, but I find your answer insufficient..  If I'm understanding your properly, you're saying that if I have a grid with data that changes at the field level, than it's too performance intensive to process?  

The collection is changed in so much that a field on a record in the collection has changed..  This doesn't intrinsically cause a reset at the collection level, but should be handled by the grid regardless as a standard part of sorting..  

You're already updating what I see in the grid when a property changes at the row level..  So you're handling that event..  All I'm saying is that if that event is handled on a column which is in the sort descriptor list, then you should be resorting it without forcing me to to a row.replace event on the collection.   It should actually be MORE efficient if you guys handle this right, than if I force a row.Replace on the collection ever time a property changes. 

?? 

-Peter

[Vlad]

Hi,

 Have you tried standard WPF DataGrid? Do you have different result compared to RadGridView?

Regards,
Vlad
the Telerik team

[Peter]

Wow Vlad, way to pass the buck.

First off, we pay for Telerik because you're providing functionality that Microsoft doesn't.  If they did everything we need, well then you wouldn't have much of a business case, eh?

So my point still stands..  1. Telerik knows which columns we're sorted on.  2. Telerik already receives the PropertyChanged events when data changes.  It should be very easy (perhaps you'd have a flag to turn this on/off) for you to say:

If (Grid.RealtimeSorting && Grid.SortedColumns.Contains(PropertyChanged.Column))
{
ProcessRowReplace(PropertyChanged.Row);
}

Please explain how that would result in: "Reapplying all these on a property change will lead to huge memory and performance problems!"

Cheers,
Peter

[Vlad]

Hi,

 What I'm trying to say is that this is how standard components similar to RadGridView will work in this case. The grid will invoke time consuming operations only when the collection bound to the grid is changed. Everything else including time consuming operations on every property change is up to the developer of the application - that is why we have provided public API for all these.

Greetings,
Vlad
the Telerik team

[Peter]

And my point is that it's much easier and more performant for the overall system for Telerik to enable this functionality than it is for us.  You're already hooked into the property changed events and the collection changed events.  For me to implement this myself, I'd have to hook into all of that myself (we have a few hundred columns, and are currently allowing multi column sort across a generated data type, so it's not exactly easy to wrap this) with some sort of wrapper around ObservableCollection, keep a secondary copy of which columns are sorted, and process all of these updates just to see if resorting is necessary.

Have a flag at the grid level for "RealtimeSorting" if you're so worried about the performance.  A boolean check per PropertyChanged should be within the envelop of acceptable performance for those who don't want this functionality.  

I'm stunned that you're so resistant to this concept.  This just adds more to the bucket of Telerik not understanding the needs of the clients..  And I'm not sure, but it feels like you guys aren't interested in any functionality needs for your existing controls.  We had a similar problem with missing functionality (or a poor design depending on your point of view) on the DockingManager.  

I need a grid that stays sorted.  It's not rocket science. 

[Mohammed]

Don't waste your breath.. I reported this issue more than a year ago and they still wouldn't fix it. End result, we're not renewing our license.

[Peter]

We've already not renewed and switched to Dev Express v12..  MUCH better..  Dev Expresses tree list control blows Telerik out of the water for performance and functionality. 

[Vlad]

Hi Peter,

 I'm not sure how the treelist is related to this thread, still maybe you can post more info on where our component is slower - as you know we always do our best to improve our performance. 

Mohammed, if we implement by default re-sort, re-filter, re-group, etc. on every property change this can lead to huge memory and performance problems. We've decided that this should depend on the developer and the scenario and we didn't introduce it by default - still we have an example with simple possible implementation. 

Regards,
Vlad
the Telerik team

[Scott]

Hi - this blog post link is broken.  Do you have an updated link, or new information on how to invoke a sort on demand?

[Hristo]

Hello David,

This is the updated link for the blog post.

Regards,
Hristo
Telerik

[Onno]

[quote]Peter said:And my point is that it's much easier and more performant for the overall system for Telerik to enable this functionality than it is for us.  You're already hooked into the property changed events and the collection changed events.  For me to implement this myself, I'd have to hook into all of that myself (we have a few hundred columns, and are currently allowing multi column sort across a generated data type, so it's not exactly easy to wrap this) with some sort of wrapper around ObservableCollection, keep a secondary copy of which columns are sorted, and process all of these updates just to see if resorting is necessary.

Have a flag at the grid level for "RealtimeSorting" if you're so worried about the performance.  A boolean check per PropertyChanged should be within the envelop of acceptable performance for those who don't want this functionality.  

I'm stunned that you're so resistant to this concept.  This just adds more to the bucket of Telerik not understanding the needs of the clients..  And I'm not sure, but it feels like you guys aren't interested in any functionality needs for your existing controls.  We had a similar problem with missing functionality (or a poor design depending on your point of view) on the DockingManager.  

I need a grid that stays sorted.  It's not rocket science. [/quote]
Funny, this is also just what we need. I googled around and had a fairly long conversation via support tickets but do not have a satisfying solution yet. All the time I was thinking exactly what Peter wrote here: The grid knows on which column it's sorted/filtered and probably listens to NotifyPropertyChanged to update its fields. Why can't it re-trigger the sort? Why do I have to create a solution (which does not seem to play nice with my MVVM pattern) to do this? 

How did you solve this?

[Nick]

Hello Onno,

Indeed RadGridView does not refresh the Sort state on PropertyChanged. The idea behind this is PerformanceOptimization, since the sorting operation can take time to be executed. And in most cases the PropertyChanges are coming in a batch, which means the Sorting should be executed many times. 
We are currently looking for a way to implement this in our data engine. In the mean time, you can use a very simple workaround to the problem - add and then remove a dummy object in your source collection, which will trigger a collection changed event that will force the sort state to be re-evaluated. 

Hope this makes sense. 

Regards,
Nik
Telerik

 

 

[Onno]

Hi Nik,

Thanks for your answer. Indeed, I am doing something similar now: replacing an item which also triggers resort/filter, as pointed out by Vlad in his blog: http://blogs.telerik.com/vladimirenchev/posts/10-10-04/fast-real-time-data-update-for-your-silverlight-and-wpf-applications.aspx. But for performance reasons I only do this when a property has changed that is bound to one of the columns that has active sorting or filtering. 

The changes for our app for this (we have quite a few grids ;)  will take me some days to implement, and I am about halfway now. I'll be very interested to hear what you come up with, since that would make those changes obsolete. Any timeline?

[Nick]

Hello Onno,

The idea is basically the same. Process the PropertyChanges and if the change is on property that is currently being used by a sort/filter/group descriptor, update the sort/filter/group state of RadGridView. 

Since this however is a very big change, it may affect a lot of our existing functionality and performance optimizations, which is why it has to be carefully tested before being released out of the box. That is why we cannot commit to a certain time frame, but will do our best to include it in one of our official releases as soon as possible. 

Regards,
Nik
Telerik

 

 

[Onno]

Cool, thanks for the update Nik! 
We will sure keep an eye out for the release that contains this.

Thanks,
Onno

[Onno]

Any news on this? It's been a while! ;-)

If the solution described by Nick is now in the RadGridView I can remove all my cumbersome work-around code so I would like to know.

Regards,

Onno

[Stefan]

Hi Onno,

Can you please take a look at the Edit an Item Outside RadGridView topic, as it demonstrates how the control can be notified when an item is modified? With this approach the data operations will be reevaluated as well.

Would this suggestion work for you, or I am missing something?

Regards,
Stefan X1
Telerik by Progress

[Onno]

Hi Stefan,

Thanks for your answer. I've looked at that link but I think that would break the MVVM pattern and offer little benefit compared to the solution we have now.

So what I am looking for is the solution discussed by Nick and Peter. 

[Stefan]

Hi Onno,

Thank you for the clarification.

As already mentioned in the previous replies, we have researched how such behavior of the control can be implemented, but this requires major modifications of some of its major functionalities. By the time being, we haven't found a clean solution for this requirement. It is logged as a feature request in our backlog, but I am adding also a public item in the Feedback Portal, so you can track its state: Add an option the data operations to be reapplied automatically on PropertyChanged.

Regards,
Stefan X1
Telerik by Progress

[Onno]

Hi Stefan,

Okay, good to know. Thanks for the update!

Regards,

Onno