In the constructor of XamPropertyGrid, it looks like there is a call to add an event handler to a static event (TypeDescriptor.Refreshed).
IE. I can put a breakpoint in the debugger and I see this method call:
System.ComponentModel.TypeDescriptor.add_Refreshed
There is never an equivalent call to release/unsubscribe from that event handler.
The result is that my app has a very rapid leak. Below is an image of the path to the rooted reference. I suppose I may have to do manual cleanup to remove the XamPropertyGrid control from my ProductDetailsControl as a workaround. But even then it will still have a leak of the XamPropertyGrid instances themselves...
Can anyone suggest any easy workarounds?
For anyone else that encounters this bug, it appears to be fixed.
The rooting of the XamPropertyGrid is not happening in Infragistics WPF 2018 Vol. 2 - Service Release 20182.281.
Hello David,
Thank you for your update on this matter.
I do not personally have much experience with the Citrix environment myself, and so I’m not sure I would really be able to provide much information on how the actual UI Automation works there. That said, I was able to reproduce this is a simple WPF-application without the Citrix environment, and so I would expect that this particular issue is related to that and not Citrix, specifically.
Regarding the bug, I don’t think there is much of a doubt that this rooting is a bug, as the issue seems to be that there is an event handler that is never unhooked. As far as an ETA, though, I do not currently have one, as the bug is not yet assigned to a developer and is in an “In Review” state. At the time of writing this, the upcoming (and final) service release for version 2018.1 is finalized and we are in a “code-frozen” state so that we can accurately perform our automated testing, but if you would like, I can see about getting this issue escalated to an upcoming bi-weekly build or the following service release?
Please let me know how you would like to proceed.
Thanks for the tip about the automation peers. I should probably know more about this stuff. Unfortunately I never enable it (accessibility) on my desktop.
I should point out that I don't enable it in Citrix either ... but it seems to be auto-enabled as a component of some funky Citrix monitoring agent. At least that is what I've been able to gather. The frustration I have with Citrix is that the members of those community forums rarely understand how their stuff works internally, and you can never get answers to questions that are technical. In order to get a WPF application to work properly in Citrix, it simply involves endless "trial-and-error". That's not how I'd prefer to spend my software development hours.
Since you were speaking with Infragistics development, have they acknowledged that the rooting of this control is a bug? Is there any approximate ETA yet on a fix?
It is interesting that the PropertyGridFilterAreaControl is still hanging on to the XamPropertyGrid in this case, but I think you are right that this could be coming from the underlying ControlTemplate of the XamPropertyGrid, as the PropertyGridFilterAreaControl is certainly a part of that template.
You can get at the PropertyGridFilterAreaControl from the XamPropertyGrid by using the Infragistics.Windows.Utilities class and its GetDescendantFromName method, like so, where “propGrid” is your local XamPropertyGrid:
var filterAreaControl = Infragistics.Windows.Utilities.GetDescendantFromName(propGrid, “PART_PropertyGridFilterAreaControl”);
This PropertyGridFilterAreaControl has a parent Grid element, and perhaps removing it from its Grid.Children could help to release it?
As a side note, I have received a comment from someone on our development team here regarding the automation peers. Rather than returning null from the OnCreateAutomationPeer element, they have recommended to create a new automation peer derived from FrameworkElementAutomationPeer and return it. In your new automation peer, you can override the GetChildrenCore method and return an empty list, as this would explicitly tell it to return no children.
Please let me know if you have any other questions or concerns on this matter.
I'm following your lead, and I'm setting a variety of private member fields to null on the XamPropertyGrid. It seems that UI automation is causing my ProductDetailsControl to be rooted via *all* of the following private fields on XamPropertyGrid:
_scrollBarInfoMediator_propertyGridFilterAreaControl_columnResizeThumb_itemLayoutPanel_flatItemList
I've set them all to null, including the field, _propertyGridFilterAreaControl. However, that particular one is still appearing in my paths to root on ProductDetailsControl. I think it is because of a control template or something like that. See image below. Notice that there are a few levels of indirection between the XamPropertyGrid and the PropertyGridFilterAreaControl.
This is starting to feel a little hopeless. It is too difficult to tear this XamPropertyGrid out of the visual tree!