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.
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?
Thank you.
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