I have a RadGridView bound to an ObservableCollection. This collection is constantly updated and on the first binding, the grid shows the data correctly. But then when I rebind the collection (through a search button), it duplicates the rows while the underlying collection contains correct data.
It only happens when the LoadData mode is Asynchronous. If I change it to Synchronous, it does not happen.
Besides, on the OnItemSourceChanged I modify the filterDescriptor. I know that Rebinding the collection on the event OnItemSourceChanged is very expensive and it is not an option.
It does not happen when debugging it either. Only in execution time. And it does not happen when putting a Thread.Sleep on the load. That is the reason why I am positive that it is an issue of synchronizing the threads. As the Asynchronous mode loads the data in a different thread while it only shows the ones fitting the grid, it has a thread to show the data on the UI and another to populate it. If we add processing to the OnItemSourceChanged, the thread will not wait (or join) the other (the one displaying the data) and will duplicate it in execution time.
Of course that when debugging it, we will see in the thread stack that there are 2 main threads, one drawing and the other one in wait/join state. As it is a bundled in resource (LoadDataMode="Asynchronous"), I can not override the handlers of the background worker that performs these actions. I can always use another technique to load up the required information asynchronously (like a backgroundworker handling the doWork events and changing the displayed data on the scroll down event, for example; also with paging programatically; restful services; etc). But I wanted to use the Telerik recommended controls.
Is there a way to override the handling of those different threads so that I can light them up and synchronize them on my own? Could there be another solution to this issue?
18 Answers, 1 is accepted
This is a known bug which manifests in some scenarios. Currently the only workaround is to disable the Async DataLoadMode. Is Async mode required for your application? RadGridView should be able to take care of a lot of data even in Synchronous mode.
the Telerik team
What's your grid version? Do you have the same problems using our latest official version - Q3 2011 SP1?All the best,
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>
Is there is any solution to the issue?
Thanks for helping.
I've managed to get rid of the duplicates in my project by uninstalling the Telerik WPF controls and installing a slightly older version. Specifically, I used the installer RadControls_for_WPF_2012_3_1129_Dev.msi.
Perhaps the uninstall did something or Telerik have introduced a bug in the latest version. It's probably worth a try for you.
I still have this problem.
Here the background information:
Telerik Release: 2018.2.709.45
RadGridView + VirtualQueryableCollectionView
The problem occurs in the following situation:
I grouped the elements in the RadGridView and did some customized DragDrop stuff.
The result of the drop is, that the database table that the VirtualQueryableCollectionView is looking on changes.
To apply the changes in the RadGridView, I call the Refresh() method of VirtualQueryableCollectionView.
That results in a refresh but also in 2 of 7 cases it leads to showing duplicate items in the group that was moved with drag and drop.
I tried DataLoadMode=Synchronous (what did not change the behavior) and EnableRowVirtualization=false (what results in a veeeeery slow application and therfore is NOT an option).
Are there any other things I may try?
Although I am not aware of the exact setup you are using, can you please try setting the GroupRenderMode of RadGridView to Flat? This is the newer virtualization mechanism of the control and has a lot of improvements and fixes compared to the older and default Nested one. More information can be found in the Grouping Modes topic.
Does the Flat mode make any difference?
I use the VirtualQueryablecollectionView with EF Core 2.1.2 (I hand a query of a DbSet in the context to the Collection's constructor) and SQL Server 2008.
I tried GroupRenderMode="Flat" but fell into a deep hole :(. I got an exception that was thrown by EF Core (See attached file).
I will try to extract that problem into an example project - maybe we can find the errors on my side from that.
Sorry to hear about the exception you are experiencing.
Having a look at the StackTrace it seems that the error is raised from the framework. I am afraid that I cannot confirm the exact cause for it.
I hope you manage to pinpoint the cause for the error. If I can be of further assistance, feel free to approach me.
I was having this issue as well, and for me I resolved it by setting DataLoadMode="Asynchronous"
GroupRenderMode didn't make a difference for me
In my wpf application, I was loading data into the observable collection in a separate thread. In normal operation, it was somewhat rare for this bug to manifest - maybe once every 20 or so bindings to the grid - seemingly random.
I found that I could reproduce it almost every time by using Thread.Sleep(100) before adding my first item to the observable collection. Maybe the issue happens if the item is added to the observable collection some time between 'OnLoaded' and when the UI is rendered/layout is applied?
FYI I am using NuGet Telerik.Windows.Controls.GridView.for.Wpf v2019.1.220
Thank you for sharing your solution with the community.
I'm afraid that without being able to replicate this issue at my end, I cannot suggest the exact cause for this issue or why it seems to always be reproducible when calling the Thread.Sleep method, but if you would share an isolated project, I'd be happy to further investigate this for you.
As we weren't able to reproduce this, we can't say what could lead to this behavior. Is it possible to isolate this in a standalone project? Also, which version of our assemblies are you using in your application? If they aren't the latest one, can you download the latest version of the DLLs and try again.
Our thoughts here at Progress are with those affected by the outbreak.