I'm seeing leaks and performance problems related to UI automation (accessibility) in the XamPropertyGrid.
Is there an easy or secret way to disable this feature? I'd rather not deal with unintended consequences of an unintentional feature. In general I'm not against the concept of accessibility, but we aren't ready for supporting it if there is an added cost (and if it introduces bugs).
Currently the only way I've found is to create a new control that derives directly from XamPropertyGrid and override OnCreateAutomationPeer to return null. This seems like the long way around, and I have to believe there is another approach to accomplishing the same thing. Any help would be appreciated.
Hello David,
Thank you for your post on this matter. I am under the impression that this forum thread is coming from another one that we have together, linked here.
https://ko.infragistics.com/community/forums/f/ultimate-ui-for-wpf/119776/xampropertygrid-is-instantly-rooted
The short answer to this, is that there is no easy or “secret” property to prevent UI Automation peers from being created that I personally know of except for the override of OnCreateAutomationPeer that you have already mentioned. This is a result of the XamPropertyGrid having support for UI Automation, and is a completely intentional feature.
In the other thread, linked above, you had mentioned that you did this, and are seeing issues apparently with other automation peers – the ScrollBarAutomationPeer. This is created for the built-in WPF ScrollBar that the XamPropertyGrid uses for vertical scrolling, and we have no control over this. Something you could potentially do in that case is to include the default template for the XamPropertyGrid that can be retrieved from the generic.shared.xaml file commonly found at the directory below, and replace it with a custom ScrollBar that overrides OnCreateAutomationPeer to do what is being done with the XamPropertyGrid. This is not ideal, but it is the only way I personally know to completely disable UI Automation of elements in WPF.
C:\Program Files (x86)\Infragistics\<your version here> \WPF\DefaultStyles\PropertyGrid\generic.shared.xaml
Please let me know if you have any other questions or concerns on this matter.
Andrew, thank you for confirming that there is no easy way to avoid all this overhead (memory leaks in our case) related to UI Automation (accessibility).
I had also considered digging into the XamPropertyGrid's control template but I think that is overkill for a short term workaround.
I'm hoping that the root cause of the rooted control will be fixed on your end soon, and we won't have to take such extreme measures in order to avoid memory leaks.
I will verify your answer for his question. But If you happen to have any idea why UI Automation would be enabled by default in Citrix environments, I'd love to hear. I have to keep deploying all my changes to Citrix to detect these leaks in UI Automation. On my own desktop I don't have the leaks because I never use UI Automation (accessibility). For some reason we don't have any control over this in Citrix. Citrix is a strange beast for sure.
Thank you for your update.
As far as I know, this does not seem like a Citrix-specific thing, as I am able to see the same memory leak as discussed in the other forum thread in a simple WPF application. I cannot say why there would be memory leaks with UI Automation and specifically Citrix, though, as I am not very familiar with that environment.