Dear support team,
attached is an example solution which causes on our machines the effect that the DockManager allocates memory for the tabs but dont release it when the tab is closed.
Hello,
Thank you for your post. I have been looking into your issue and I was wondering why you are thinking that there is memory leak when you close the content panes. When a content pane is close it is removed from the panes collection of the TabGroupPane.
Looking forward to hearing from you.
I am just checking if you require any further assistance on the matter.
I think i have the same problem as mentioned in this post. I have recently downloaded a source project from http://brianlagunas.com/xamdockmanager-prism-region-adapter-update-3/. I found this is very useful as it is implemented using prism concept. I made some changes on this source code and I tested the memory usage using memory profiler. fyi, My company is currently using Infragistics product.
I found that when closing the Pane from the UI, sometimes it can be disposed successfully, sometimes it is can't. Here i attached the source code with the changes i made. How can i ensure that the content pane can be disposed properly when it is closed? I have posted the same problem in http://brianlagunas.com/xamdockmanager-prism-region-adapter-update-3/. Hope to hear from you soon.
Thank you.
I have been looking into your question and you may try to dispose a content pane on closing handling its ’Closing’ event like:
private void PaneClosing(object sender, PaneClosingEventArgs e)
{
Dispatcher.BeginInvoke(new Action(() =>
GC.Collect();
GC.WaitForPendingFinalizers();
}), System.Windows.Threading.DispatcherPriority.Background);
}
Please in future create a separate thread for each of your new question.
Hope this helps you.
Hi Team,
We are also facing the same issue with our application. if we have opened a tab then memory is increased but once we closed tab memory is not releasing. we are using Infragistics 2016 v1. please let us know if this issue has been fixed or not or what is the solution for it. since it is causing big problem so please reply soon
Thanks in advance
Hello T CC,
I have logged this behavior with our developers in our tracking system, with an issue ID of 170565. I have also created a support ticket on your behalf with number CAS-135868-H1P4F4 in order to link the development issue to it so that you are automatically updated when a Service Release containing your fix is available for download.
Hi,
Is there any updates for the memory leak issue?
Thanks everyone for the big help. :)
Hope Ms can fix this issue asap.
After looking into this issue, it has been determined that this is a bug in the WPF framework. The flaw/problem is that the ItemsControlAutomationPeer maintains a strong reference to the items from the ItemsCollection in its _WeakRefElementProxyStorage. That is a sort of weak dictionary where the key is the item (held with strong reference) and the weakly held reference is the ElementProxy – an object that represents the automation peer associated with the item. They only seem to clean this up during a couple of interaction points with the ItemsControlAutomationPeer – one of which is UpdateChildren. That would be ok except the criteria they use to decide whether to remove an item from that proxy storage is solely based on whether the ElementProxy that is weakly held is still alive. As long as it is then they keep a strong reference to the item.
MS needs to fix this in the WPF framework. Here is a link to the bug report:
https://connect.microsoft.com/VisualStudio/feedback/details/838165/memory-leak-in-the-itemscontrolautomationpeer-because-items-removed-from-the-itemscollection-are-still-strongly-held-by-the-weakrefelementproxystorage