I am trying to program an automatic tester application using the new native Microsoft UI Automation 3.0 interface (in VC ++ 2010, Win7). The application under testing (AUT) is a WPF application.
Almost everything works fine ... I can install event handlers, navigate the tree, search elements using various conditions, and manage the elements found using their templates.
But yesterday I found a behavior that leaves me desperate: The UIA tree of my AUT just doesn't update after switching its main panel by clicking on one of its main menu buttons.
After clicking the main menu button, I see new widgets in the AUT GUI, but the UIA tree still contains the controls that were there before clicking the main menu button. The (obsolete) UIA tree can be completely read using the search functions or using the walker, but of course it cannot be written because widgets no longer exist.
This looks exactly like an outdated cache ... however, I DO NOT use any UIA caching features at all. No one. Never. Nowhere.
I could not update the UIA tree programmatically ... either by calling any UIA functions, by restarting the tester application, or by switching the AUT GUI back and forth. This does not happen every time. Sometimes, after pressing the main button, the tree seems to be updated accordingly, and everything works fine. However, most runs fail. There is only one (mysterious) way that reliably updates the UIA tree: Using inspect.exe. When using the inspect.exe tool to briefly view the AUT UIA subitem, the problem suddenly disappeared, and my tester application can immediately access the actual updated tree! Of course, the problem reappears after restarting AUT.
What does inspect.exe do to update the UIA tree (of another application !!!)? How is it possible to access elements without using caching? What did I miss?
I really need some help.
Ok, a few more conclusions:
UISpy.exe is able to update the UIA tree in the same mysterious way that ex.exe checks (this is especially strange because index.exe uses the same native interface as I do, but UISpy.exe uses the .NET interface, I am KNOWN) . This means that this is a kind of systemic and persistent UIA problem, and not a pure problem with the native UIA.
The problem does not occur if I do not access the tree before switching the view. That is, if my tester application does not have access to view AUT before switching the view, by pressing the main menu button, it sees new widgets without problems. This strongly indicates some caching problem with the native UIA APIs - even if I don’t know how this can happen because I don’t cache at all. Does anyone know if there is some kind of internal caching?
I think this may be an API error. However, given my current experiences with Microsoft Connect, I’m kinda lost with this showstopper: - (
Somebody knows?
I also tested the Snoop tool. Using Snoop does NOT heal the problem temporarily, like Inspect and UISpy. As for Inspect.exe, there is one more detail ... just collapse and expand the AUT subdirectory to temporarily fix the problem.