I am trying programming an automated tester application using the new native Microsoft UI Automation interface 3.0 (in VC++ 2010, Win7). The Application Under Test (AUT) is a WPF application.
Almost everything works fine… I can install event handlers, navigate through the tree, search elements using various conditions and control the found elements using their patterns.
But yesterday I found a behaviour that leaves me despaired: The UIA tree of my AUT simply is not updated after switching its GUI main panel by clicking one of its main menu buttons.
After clicking the main menu button, I can see the new widgets in the AUT’s GUI but the UIA tree still contains the controls that have been there before clicking the main menu button. The (outdated) UIA tree can be still completely read using search functions or using walker but of course it can not be written since the widgets do not exist anymore.
This exactly looks like there would be an outdated cache… however I do NOT use any caching UIA functions at all. None. Never. Nowhere.
I was not able to make the UIA tree update programatically… neither by calling any UIA functions nor by restarting the tester application nor by switching the AUT’s GUI back and forth.
This does not happen every time. Sometimes after clicking the main button the tree seems properly up-to-date and everything works fine. However most of the runs it fails.
There is only one (mysterious) way that updates the UIA tree reliably: Using inspect.exe. When using inspect.exe tool for having a brief look into the AUT’s UIA sub tree, the problem is suddenly gone and my tester application can access the actual, updated tree immediately! Of course the problem re-appears after restarting the AUT.
What does inspect.exe do to make the UIA tree (of another application!!!) update? How is it possible at all to access gone elements without using any caching? What did I miss?
I really need help.
Ok, some more findings:
-
UISpy.exe is able to refresh the UIA tree the same mysterious way inspect.exe does (this is especially strange because inspect.exe uses the same native interface as I do but UISpy.exe uses the .NET interface AFAIK). This means this is a kind of system wide and persistent UIA problem and not a pure native-UIA-problem.
-
The problem does not happend if I do not access the tree before switching the view. I.e. if my tester application does not access the AUT’S view before switching the view by clicking the main menu button, it sees the new widgets without problems. This strongly indicates some caching problem of the native UIA API – even if I have no idea how this could happen because I do not caching at all. Does someone know if there is some internal caching taking place?
I think this could be a API bug. However considering my current experiences with Microsoft Connect I am kind of lost with that showstopper 🙁
Someone any idea?
I also tested the Snoop tool. Using Snoop does NOT heal the problem temporarily like Inspect and UISpy do. Regarding Inspect.exe, there is another detail… it is enough to collapse and expands the AUT’s sub-tree to temporarily heal the problem.
Ok, update on this. UIA simply seems horribly buggy. I found that reading an element’s content array and the length of that array updates the hidden caches. I also had a case where a subtree of a tab was not update but could be updated by switching to another tab and back (reading the content by pattern did NOT help in that case). Both cases were reproducable but I could not find any way to predict or prevent them. Also al lot of third party WPF components seem to be buggy. We finally gave up to use that API.