UISpy 和 UIA 验证在同一程序上显示不同的属性值
我正在测试一个程序，它的关闭按钮在某一点启用，在另一点禁用。 UISpy 在两个点上都显示“isEnabled”为“true” UIAVerify 在第一个点显示“isEnabled”为“true”，在第二个点显示为“false”，
后者是我可以直观地确认为真的，以编程方式我得到与 UISpy 相同的值，我的测试用例是失败。
使用系统.Windows.自动化；
树结构： “对话框”“程序名称” “标题栏”“程序名称” “按钮”“关闭”
有人知道是什么原因造成的吗？ UIA verify 使用与 UISpy 不同的库吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
UIA 验证 2.0 使用较新的本机 COM UIA 库，该库在 UIA 3.0 更新中与 Windows 7 一起发布（也可作为 Vista 和 XP SP3 的单独修补程序 KB971513）。另一方面，我认为 UISpy 使用原始的托管 API。
我使用
.isEnabled()和.invoke()方法在托管库方面遇到了间歇性问题，我可以通过迁移到 COM 库来纠正这些问题，这似乎总体上比托管库更稳定、更快。我不记得迁移过程的细节，但基本上您需要生成一个互操作 DLL，以允许您的 .NET 应用程序调用本机 UIA 方法。然后，您可以选择创建自己的包装器库，或者可能使用下面提到的其中之一。
我建议参考这些内容以获取转换过程中的帮助：
UI Automation COM-to-.NET Adapter - 为 COM API 创建包装器的早期尝试。我直接使用它时遇到了麻烦，但最初看一下很有帮助。另请搜索一些有关此包装器开发人员制作的 COM API 的 MSDN 支持论坛帖子。不幸的是，由于我的 StackOverflow 代表较低（长时间潜伏，第一次回答），我无法链接到他们。
UIA 验证源代码 - 您可以看到他们有他们的源代码是 UIAComWrapper，用于访问 COM 接口。您还可以在该项目中查看他们如何生成互操作 DLL。
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.