I have a program I'm testing that has its close button enabled at one point and disabled at another. UISpy shows 'isEnabled' at both points to be 'true' UIAVerify shows 'isEnabled' at the first point to be 'true' and at the second to be 'false'
The latter is what I can visually confirm to be true, programmatically I'm getting the same values as UISpy and my test case is failing.
using System.Windows.Automation;
Tree Structure: "Dialog" "ProgramName" "title bar" "ProgramName" "button" "Close"
Is anyone aware of what could be causing this? Does UIA Verify use a different library than UISpy?
UIA Verify 2.0 uses the newer native COM UIA library that was released in the UIA 3.0 update alongside Windows 7 (also available as a separate hotfix KB971513 for Vista and XP SP3). UISpy on the other hand I think uses the original managed API.
I had intermittent issues with the managed library with the
.isEnabled()and.invoke()methods that I was able to correct by migrating over to the COM library, which seems to be more stable and faster overall than the managed library.I can't recall the specifics of the process of migrating over, but basically you'll need to produce an interop DLL that will allow your .NET application to call the native UIA methods. Then you can optionally create your own wrapper library or possibly use one of those mentioned below.
I'd recommend referring to these for help in making the transition:
UI Automation COM-to-.NET Adapter - An early attempt at creating a wrapper for the COM API. I had trouble just straight up using this, but it was helpful to take a look at initially. Also search for some of the MSDN support forum posts about the COM API made by this wrapper's developer. I unfortunately can't link to them because of my low StackOverflow rep (long time lurker, first time answerer).
UIA Verify Source Code - You can see that they have in their source code a UIAComWrapper which is used to access the COM interface. You can also take a look in that project at how they're producing the interop DLL.