Hi,
In our application, we have a number of static data sources we keep as a cache for commonly used drop down lists so they don't have to be repopulated from the data source. I am doing some memory profiling and am finding that after opening and closing our forms, there are many instances of the CollectionChangeEventHandler not being garbage collected. It happens when I bind datatables, IBindingList collections, or BindingList<> sources in both the UltraCombo and the UltraWinGrid. I have tried setting the UltraCombo.Datasource = null when disposing the control, but it won't release the ListChangedEventHandler. Am I doing something wrong? How can I get the UltraCombo and UltraWinGrid to 'unhook' these events when we dispose of them?
Thanks.
Hi Colin,
I ran your sample and I do indeed see an increase in the number of CollectionChangeEventHandlers each time I open and close the form. It increases by 2, in fact.
I looked into the grid code, though, and I don't see anything the grid is doing wrong. It's hooking and unhooking the event an equal number of times.
So I looked into what's rooting the class instances and it appears that the DotNet BindingManager is hooking the ListChanged event of the DataView and never releasing it.
So this appears to be a bug in the DotNet Framework and not the grid or the combo. To further verify this, I removed all Infragistics controls and references from your sample and replaced the Combo with a DataGridView and re-ran the performance profiler test. Sure enough, I get exactly the same results.
Thanks for that Mike, worst possible result though.
I tried to follow your link to the Microsoft Connect article that it mentions and surprise surprise it isn't there any more. I suppose MS don't want the world knowing millions of applications have a memory leak.
I found a post here which describes some potential binding memory leaks. There's a reply that seems promising which starts with "Setting the GridControl.DataSource property" which suggests that using a BindingSource might help.
I tried it and it doesn't seem to make any difference to the number of CollectionChangeEventHandlers. And in fact, overall memory usage seems to go up in my testing. But I thought I'd mention it just in case something else here helps you find a solution.