I had a lot of problems with WPF AutomationPeer too.
You may be able to solve your problem by forcing the WPF interface elements to use a custom AutomationPeer that behaves differently by default without returning AutomationPeers child controls. This may stop any user interface automation, but I hope that in your case, like mine, you do not use user interface automation.
Create your own automation peer class that inherits from FrameworkElementAutomationPeer and overrides the GetChildrenCore method to return an empty list instead of peer control controllers. This should stop problems when trying to iterate through the AutomationPeers tree.
Also override GetAutomationControlTypeCore to indicate the type of control in which the automation parameter will be used. In this example, I pass AutomationControlType as a constructor parameter. If you apply your own automation manager to your Windows, it should solve your problems since I think the root element is used to return all children.
public class MockAutomationPeer : FrameworkElementAutomationPeer { AutomationControlType _controlType; public MockAutomationPeer(FrameworkElement owner, AutomationControlType controlType) : base(owner) { _controlType = controlType; } protected override string GetNameCore() { return "MockAutomationPeer"; } protected override AutomationControlType GetAutomationControlTypeCore() { return _controlType; } protected override List<AutomationPeer> GetChildrenCore() { return new List<AutomationPeer>(); } }
To use a custom peer, override the OnCreateAutomationPeer method in a user interface element, for example. Window:
protected override System.Windows.Automation.Peers.AutomationPeer OnCreateAutomationPeer() { return new MockAutomationPeer(this, AutomationControlType.Window); }
Glen thomas
source share