UI自动化和远程桌面连接
我有一个应用程序可以对任意 Windows 应用程序执行一些自动化操作。我一直用记事本来测试它。
在此自动化过程中，我必须从代码中调用事件。我目前支持两种类型的事件，因为它们似乎是最常见的， InvokePattern 和 ExpandCollapsePattern。
我使用一台可以远程桌面进入的计算机来进行测试。但这很奇怪。当我通过远程桌面连接到计算机时，该应用程序运行良好。当我与计算机断开连接时，我的代码停止为 ExpandCollapsePattern 工作（InvokePattern 工作正常）。我收到 InvalidOperationException。
文档说只有当节点被标记为 LeafNode 时才应该抛出此错误。远程桌面有何不同导致我收到 InvalidOperationException？
这是我当前必须执行该事件的代码。
ExpandCollapseState state =
patternMenu.Current.ExpandCollapseState;
if (state == ExpandCollapseState.Expanded)
patternMenu.Collapse();
else if (state == ExpandCollapseState.PartiallyExpanded ||
state == ExpandCollapseState.Collapsed)
patternMenu.Expand();
patternMenu 是使用 GetCurrentPattern 从 AutomationElement 获取的 ExpandCollapsePattern。
当我打印出该值时，ExpandCollapseState 的当前值为“Collapsed”。
编辑：我有机会知道为什么我得到了否决票以及这是一个糟糕的问题吗？我真的对发生的事情感到困惑，因为它似乎只有在远程桌面关闭时才会失败。如果这是一个非常愚蠢的问题，我应该知道答案，我希望得到解释，然后投反对票。
与桌面交互的进程不是 Windows 服务。这是我在远程桌面进入计算机后启动的应用程序。是因为我锁定了桌面吗？
我在 Ubuntu 上使用“终端服务器客户端”登录 Windows 计算机。按此应用程序上的关闭按钮是否会导致桌面锁定？
I have an application that does some automation on an arbitrary Windows application. I've been using Notepad to test it.
During this automation, I have to invoke events from the code. I currently support two types of events since they seem to be the most common, InvokePattern and ExpandCollapsePattern.
I use a computer that I can remote desktop into to do the testing. But it's weird. When I'm connected to the computer through Remote Desktop, the application works fine. When I disconnect from the computer, my code stops working for the ExpandCollapsePattern (InvokePattern works fine). I get an InvalidOperationException.
The documentation says that this should only be thrown if the node is marked as a LeafNode. What makes Remote Desktop different that I'm getting the InvalidOperationException?
Here is the code I currently have to perform the event.
ExpandCollapseState state =
patternMenu.Current.ExpandCollapseState;
if (state == ExpandCollapseState.Expanded)
patternMenu.Collapse();
else if (state == ExpandCollapseState.PartiallyExpanded ||
state == ExpandCollapseState.Collapsed)
patternMenu.Expand();
patternMenu is an ExpandCollapsePattern gotten from the AutomationElement using GetCurrentPattern.
The current value of ExpandCollapseState is "Collapsed" when I print out the value.
EDIT: Any chance I can know why I got a downvote and how this is a bad question? I'm genuinely confused of what's happening, as it only seems to fail when remote desktop is closed. If this is a really dumb question that I should know the answer to, I'd love an explanation and then a downvote.
The process that interacts with the desktop isn't a Windows service. It's an application I start after I remote desktop into the computer. Is it because I'm locking the desktop?
I'm using "Terminal Server Client" on Ubuntu to log into the Windows machine. Does pressing the close button on this application cause the desktop to lock?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，您通常无法在非交互式桌面上运行 UI 自动化或类似功能。非交互式桌面在输入方面有各种限制：没有焦点元素，无法发送输入，因此依赖于这些的任何操作都会失败。
某些功能（例如发送 Windows 消息）可以正常工作。这里可能发生的情况是 InvokePattern 功能在幕后作为消息实现，因此仍然有效；但展开/折叠可能会根据输入来实现，这会失败。
不清楚为什么在您的情况下，当您关闭客户端时它会失败（该部分是预期的），但是
当远程桌面锁定自身时，它似乎可以工作 - 它在两种情况下是否会表现相同。
（请注意，如果本地 Ubuntu 桌面锁定，只要客户端仍在运行，一切都应该很好并且仍然可以工作。在这种情况下，远程客户端仍然是“交互式”的，因为它有一个实时的附加到它的客户端，无论客户端本身是在交互式还是非交互式桌面上运行 - 这些概念甚至可能不适用于在另一个操作系统上运行的客户端！）
Generally speaking, you can't typically run UI Automation or similar on a non-interactive desktop. Non-interactive desktops have various limitations regarding input: there's no focused element, input can't be sent, so anything that depends on these will fail.
Some functionality, such as sending windows messages, will work fine. What might be happening here is that the InvokePattern functionality is implemented under the covers as messages, so still works; but the Expand/Collapse might be implemented in terms of input, which would fail.
Not clear why, in your case, it fails when you close the client (that part is expected), but
appears to work when the remote desktop locks itself - would it expect to behave the same in both cases.
(Note that if the local Ubuntu desktop locks, all should be fine and still work, so long as the client still running. The remote client is still 'interactive' in that case, since it's got a live client attached to it, regardless of whether the client itself is running on an interactive or non-interactive desktop - the concepts may not even apply to a client running on another OS!)