Grid Filtering with QueryableEntityCollection causing ObjectDisposed Error

[Brian]

I have an MVVM .Net 4.0 WPF application connecting to a database through entity framework.  I have a tab control where each tab is a distinct view.  Each of these tabs needs to maintain its own DBContext - so that when a tab is selected the previous tab’s context is disposed and the context for the new tab is created and will remain until the user leaves the tab.

This works fine while just navigating the items listed or paging through the items using the data pager control.  When a filter is applied, I can navigate away from the tab without issue, but when I navigate back to it, I get an ObjectDisposed exception on the ObjectContext when the onPropertyChanged is called for the bound QueryableEntityCollectionView.

Is there any means of avoiding this exception?  I’ve tried a number of different configurations and conditions to eliminate this, but can’t seem to find a solution. 

To demonstrate, I’ve attached a simple example that uses the AdventureWorks DB.  You’ll have to tweak the connection string in the app.config.

 You can browse and navigate between the Products and Employees tabs without issue until you apply a filter to one tab, leave it and then comeback to it.

 

Thanks for any help you can provide.

 Brian

[Rossen Hristov]

Hi,

That is expected. If you are going to kill your context each time, then you will have to dispose the QECV as well and then to re-create a brand new QueryableEntityCollectionView each time with the new context. They have to live hand by hand, i.e. when the one is gone the other is useless and should die too.

Here is something important. If you are not doing any CRUD operations, then you don't need the QueryableEntityCollectionView at all. You can directly bind the grid to the respective query on your context, i.e. for example Employees, since it already implements the IQueryable and IEnumerable interfaces and the grid and the pager will do all of their stuff (like filtering, sorting, grouping, paging) directly on the server. The only reason we have developer the RadEntityFrameworkDataSource is to enable the grid to do CRUD out-of-the-box with EF. You can simplify your application a lot if you can totally omit the QECV. Of course, if you are going to kill the DBContext each time, you will need to rebind the grid to the new object query each time.

Let me know if this does not help.

Regards,
Rossen Hristov
Telerik

[Brian]

Thanks for the quick reply.  I am doint CRUD operations, so I'll need the QueryableEntityCollectionView.

Disposing the QECV didn't seem to resolve the issue.
I added the dispose in the closeDBContexts method (just prior to disposing the dbContext) and I still have the problem. 

When leaving the form the QECV is disposed, but when the view is displayed again the ObjectDisposed exception is still thrown when the QECV gets set.  This is only happens when a filter or sorting has been applied before leaving the view the first time.

Steps to reproduce in the attached sample:
1. Click LoadTabs
2. Add a filter to one of the products columns.
3. Click the Emploees tab.
4. Click the Products tab to throw the exception

[Rossen Hristov]

Hello,

Please, remove the DataLoadMode="Asynchronous" setting from the grid. It is totally useless and obsolete (we will remove it soon) but nevertheless causes the exception that you see -- it is a long story.

Also, in your closeDBContexts methods set the QECV instance to null after you dispose it -- just like this context, i.e:

Products.Dispose()
Products = Nothing
m_dbContext.Dispose()
m_dbContext = Nothing

They (the QECV and the context) are born together, live together and then they have to die together.

Of course you will lose all existing filtering, sorting, grouping and so on, but that is expected since you want to dispose everything.

Let me know if that does not help.

Regards,

Rossen Hristov
Telerik

[Brian]

Removing DataLoadMode="Asynchronous" and setting the QECV to nothing did remove the exception.  I don't know that the Asynchronous setting was 'totally' useless.  When it was set, there was an overlay with a spinner circle that displayed over the grid when it was waiting for data to come back.  Without this the UI just appears unresponsive.  It was nice that this visual waiting indicator was just built in. 

Anyway, thanks for your assistance getting around the exception.  The filtering and sorting are reset as expected.  However, even though the grid isn't filtered when I come back to it, the previous filter selection still appears in the filter UI popup.  What's the best way to reset this?

[Rossen Hristov]

Hi,

You can clear all the filters programmatically as described in this article.

Me.radGridView.FilterDescriptors.SuspendNotifications()
For Each column As Telerik.Windows.Controls.GridViewColumn In Me.radGridView.Columns
    column.ClearFilters()
Next
Me.radGridView.FilterDescriptors.ResumeNotifications()

Regards,

Rossen Hristov
Telerik

[Brian]

Thanks.  That worked.

One more thing.  I was watching sql profiler and noticed that if I had a filter set and then set the QECV to nothing (when leaving a tab right before disposing of the dbcontext) that a couple queries get run.  Is there anyway to prevent these?  Any calls to the database when setting the QECV to nothing are just a waste of resources.

[Rossen Hristov]

Hello,

Please, excuse me for the delay. I will need some more time to investigate this issue. I will let you know immediately when I found out what is going on.

Thank you for your understanding.

Regards,
Rossen Hristov
Telerik

[Rossen Hristov]

Hi,

We have managed to fix this issue so that the QECV is not making any server requests after it has been disposed. The fix will be available in the very first "Latest Internal Build" after the upcoming 2013 Q2 Release.

Let us know if you find any other issues.

Regards,
Rossen Hristov
Telerik