Our (monster) app has a memory leak that seems to be caused in part by a TabItemExAutomationPeer hanging around after our user control (containing a tab control) is unloaded. I'm a bit surprised this thing exists at all, since I'm under the impression that it's only for UI automation (testing), but what do I know? Is it created automatically by IG? (If not, I have to consider the possibility that some bright person is creating it in our app just so they can simulate a button-click or something. :( )
If IG creates it, how do I get rid of it?
Thanks.
Hello,
I am just checking if my last reply was helpful for you.
If you require any further assistance please do not hesitate to ask.
Sincerely,
Horen
Software Developer
Infragistics
Hi, John,
Here is a stackoverflow discussion regarding UI automation "disabling" that may be helpful for you
http://stackoverflow.com/questions/17297539/can-ui-automation-be-disabled-for-an-entire-wpf-4-0-app
Hope this could provide a workaround for your issue.
Thank you for using Infragistics Components.
Hi, Horen, thanks for your reply. That's an interesting MS bug discussion. Yes, SciTech dotNet memory profiler 5.0 shows this thing hanging around. And, as the MS bug poster said, the object graph rooted at this automation peer eventually leads into our view and view model. I was hoping I could sever the reference to the automation peer somehow and get all the rest cleaned up, but I guess it ain't gonna happen. :(
John.
Hello John,
The UI Automation peers are created when the system has a ui automation client running likely the touch keyboard, magnifier, or any number of applications including accessibility related apps as that’s pretty common - the WPF framework creates the peers (by calling into the OnCreateAutomationPeer virtual method) when it needs the peer.
Note, the xamTabControl is just a derived TabControl and TabControl itself has automation peer support so I’d suggest finding out if your issue manifests when just using a TabControl.
Also this maybe an issue that was submitted to Microsoft : https://connect.microsoft.com/VisualStudio/feedbackdetail/view/838165/memory-leak-in-the-itemscontrolautomationpeer-because-items-removed-from-the-itemscollection-are-still-strongly-held-by-the-weakrefelementproxystorage but they disided that not a bug because ultimately the memory will be released.
Did you use a memory profiler to determine the leak and the root paths for the objects you feel should be released?