AutomationElement：缓存元素（通过 GetCachedChildren）“存活”元素
我有一个 ComboBox，其中包含一个列表（这是组合框的标准），其中包含很多元素 - 超过 100 个。我想找到某些条目来选择它们。为了查找条目，我将给定模式与每个元素的名称进行比较。
出于性能原因（超过 100 个元素），我在父级上使用 CacheRequest，其范围包括所有子级，因此我可以很好且非常快速地遍历所有子级并找到我想要选择的子级的正确索引。
问题来了：我有我想要的正确索引，我也有缓存的 AutomationElement，但是由于我在 CacheRequest 中指定了 AutomationElementMode.None （我仍然需要测试它是否对性能产生影响），所以我似乎不是能够将缓存的元素转换为我可以用于将来调用的元素（“实时”元素）。
我尝试通过NativeWindowHandle进行转换（因为有一个函数AutomationElement.FromWindowHandle），但是句柄似乎是0，所以这是没有办法的。
我还没有尝试使用缓存的 SelectionPattern - 由于组合框有时是自定义构建的，我不知道这是否适用于所有情况（如果有的话）。
我有子索引，我可以获得所有可以缓存的值 - 如何获得缓存元素的工作/实时 AutomationElement？
谢谢 Andreas
（在 Windows 7 64 上使用 C# 和 win32 应用程序（作为自动化目标），尽管这应该不会产生太大影响）
I have a ComboBox containing a list (which is standard for a combobox) that has a lot of elements - more than 100. I want to find certain entries to select them. To find the entries, I compare a given pattern to the name of each element.
For performance reasons (more than 100 elements), I am using a CacheRequest on the parent with a scope of all children, so I can nicely and very quickly go through all the children and find the correct index of the child I want to select.
Here comes the problem: I have the correct index I want, I also have the cached AutomationElement, but since I specified AutomationElementMode.None in the CacheRequest (I still have to test if it gives an impact on performance), I seem not to be able to convert the cached element to one I can use for future calls (a "live" element).
I tried conversion via NativeWindowHandle (since there is a function AutomationElement.FromWindowHandle), but the handle seems to be 0, so this is no way.
I also have not tried to use a cached SelectionPattern yet - since the ComboBoxes are sometimes custom built, I don't know whether that would work in all cases though (if any at all).
I have the child-index, I can get all the values I could cache - how can I get a working/live AutomationElement of the cached element?
Thanks
Andreas
(using C# on Windows 7 64 with a win32 application (as automation target), though that should not make a big difference)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除了索引之外，您还有需要的子文本吗？如果是这样，是否可以将子文本发送到组合框，就像用户键入以选择您需要的子文本一样，而不是尝试获取自动化元素？
总是有 IUIAutomationLegacyIAccessiblePattern 可以依靠，但我认为这仅在核心 API 中，而不是在客户端 (AutomationElement) 中。
Do you have the child text that you need in addition to the index? If so, would it be possible to send the child text to the combo box as if a user were typing to select the child that you need instead of trying to get an automation element?
There is always the IUIAutomationLegacyIAccessiblePattern to fall back on, but I think that is only in the core API and not the client (AutomationElement).
实际上，使用 AutomationElementMode.None 似乎不是最好的主意。缓存请求所花费的时间似乎仅受您是否请求活动元素以及您请求的属性数量的影响很小。 （如果我错了，请纠正我 - 我没有系统地测试，但最近在尝试缓存请求上的一些选项时有这种感觉。）
它似乎主要受到您首先请求的 UI 元素数量的影响。
所以我可以首先请求实时链接。
这让我现在想知道通过某些 Win32SDK 函数访问是否会更快。
Actually, using AutomationElementMode.None seems to have been not the best idea. The time a cache requests takes seems to be only marginally influenced by whether you request a live element and how many properties you request. (Correct me if I am wrong - I did not test systematically but got that feeling recently when toying around with some options on my cache request.)
It seems to be mostly influenced by the number of UI elements you request in the first place.
So I could request a live link in the first place.
That makes me wonder now whether access through some Win32SDK function would be any faster..