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.
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.
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(() =>
Please in future create a separate thread for each of your new question.
Hope this helps you.
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: