How can Accessibility Insights succeed in walking UIAutomation Tree of Chromium Embedded Framework App, but Inspect and my code can't?

Question

I'm using Microsoft's UIAutomation framework to retrieve information from an app that is built on the Chromium Embedded Framework. My code is failing to find the needed information, so I brought out inspect.exe to look at the tree. Sure enough, Inspect shows just a single descending line of "pane" elements, nothing like the actual application. My application mirrors that behavior.

However, Accessibility Insights, is able to walk the real tree and see all the widgets that I need to scan. Does anyone have any idea what Accessibility Insights is doing differently, such that they have success where I am failing and how I can duplicate that?

I took at look at Initialize UIautomation tree from an element whose ClassName is Chrome_RenderWidgetHostHWND. Accessability Insights, but that doesn't seem to show how the element was able to be chosen in the first place. I need to programmatically find the children, rather than relying on any user interaction.

Answer 1

I resolved this issue by doing the following:

I set a StructureChanged event handler on the highest-level window, giving it a TreeScope_Descendants scope. One of the events that was thrown was thrown by the element that I actually wanted to watch. Once I had the IUIAutomationElementPtr that referred to that element, I could set the real event handler I wanted, and traverse the tree using that element as the base.

So even though I couldn't start at the highest-level window and go down, I could go both down and up the tree from that newly-found element. So even though I wasn't able to get the answer to my question, I found a work-around.