- 概述
- 用户界面自动化
- 通过用户界面自动化实现自动化的应用程序和技术
- 项目兼容性
- UI-ANA-016 - 拉取打开浏览器 URL
- UI-ANA-017 - 出错时继续 True
- UI-ANA-018 - 列出 OCR/图像活动
- UI-DBP-006 - 容器使用情况
- UI-DBP-013 - Excel 自动化误用
- UI-DBP-030 - 选取器中的禁止变量使用情况
- UI-PRR-001 - 模拟单击
- UI-PRR-002 - 模拟键入
- UI-PRR-003 - 打开应用程序误用
- UI-PRR-004 - 硬编码延迟
- UI-REL-001 - 选取器中的大 IDX
- UI-SEC-004 - 选取器电子邮件数据
- UI-SEC-010 - 应用程序/Url 限制
- UI-USG-011 - 不允许的属性
- UX-SEC-010 - 应用程序/Url 限制
- UX-DBP-029 - 使用不安全的密码
- UI-PST-001 - 项目设置中的审核日志级别
- UiPath 浏览器迁移工具
- 剪切区域
- 计算机视觉录制器
- 活动索引
- 激活
- 锚点基准
- 附加浏览器
- 附加窗口
- 阻止用户输入
- 标注
- 选中
- 单击
- 单击图像
- 单击图像触发器
- 单击 OCR 文本
- 单击文本
- 单击触发器
- 关闭应用程序
- 关闭选项卡
- 关闭窗口
- 上下文感知锚点
- 复制选定文本
- 元素属性更改触发器
- 存在元素
- 元素作用域
- 元素状态更改触发器
- 导出用户界面树
- 提取结构化数据
- 查找子元素
- 查找元素
- 查找图像
- 查找图像匹配项
- 查找 OCR 文本位置
- 查找相对元素
- 查找文本位置
- 获取活动窗口
- 获取上级
- 获取属性
- 获取事件信息
- 从剪贴板获取
- 获取全文
- 获取 OCR 文本
- 获取密码
- 获取位置
- 获取源元素
- 获取文本
- 获取可见文本
- 返回
- 前往
- 转至主页
- Google Cloud Vision OCR
- 隐藏窗口
- 高亮显示
- 热键触发器
- 悬停
- 悬停在图像上方
- 悬停在 OCR 文本上方
- 悬停文本
- 存在图像
- 在屏幕上指定
- 注入 .NET 代码
- 插入 Js 脚本
- 调用 ActiveX 方法
- 按键触发器
- 加载图像
- 最大化窗口
- Microsoft Azure 计算机视觉 OCR
- Microsoft OCR
- Microsoft Project Oxford Online OCR
- 最小化窗口
- 监控事件
- 鼠标触发器
- 移动窗口
- 导航至
- 存在 OCR 文本
- 在元素出现时
- 在元素消失时
- 在图像出现时
- 在图像消失时
- 打开应用程序
- 打开浏览器
- 刷新浏览器
- 重播用户事件
- 还原窗口
- 保存图像
- 选择项目
- 选择多个项目
- 发送热键
- 设置剪切区域
- 设置焦点
- 设置文本
- 设置为剪贴板
- 设置网页属性
- 显示窗口
- 启动进程
- 系统触发器
- 截取屏幕截图
- Tesseract OCR
- 存在文本
- 工具提示
- 键入
- 输入安全文本
- 使用前台
- 等待属性
- 等待元素消失
- 等待图像消失
- Computer Vision Local Server
- 移动自动化
- 终端

用户界面自动化活动
操作指南
In business process automation, users encounter cases when browser dialogs block the execution of the current browser page. Typically, the user would want to dismiss the browser dialog and also get the dialog message for later use in the business scenario.
For Windows projects this type of scenario can be handled by setting Window attach mode to Application instance for the Use Application/Browser container activity and generating the browser dialog selector with Active Accessibility (AA) UI framework.
But for Cross-platform projects (including Studio Web) we didn’t have any solution to handle this type of scenario.
JavaScript has three kind of popup boxes: Alert, Confirm and Prompt. The Browser Dialog Scope activity can handle this type of dialogs and it should be used as a scope for the activities that may generate a browser dialog.
The Browser Dialog Scope activity must be added inside a Use Application/Browser activity and the activities that could trigger the dialog must be placed in the body of the Browser Dialog Scope activity.
An Alert dialog is used to make sure information comes through to the user. When it pops up, the user will have to click the OK button to proceed, otherwise the execution is blocked.
This is how the Browser Dialog Scope activity can be configured to handle an Alert dialog that is triggered when you click a Submit button.
A Confirm dialog is used when the user needs to verify or accept something. When it pops up, the user will have to click either the OK or Cancel button to proceed.
This is how the Browser Dialog Scope activity can be configured to handle a Confirm dialog that is triggered when you click a Submit button.
A Prompt dialog is used when user needs to provide a text input for an operation. When it pops up, the user will have to click either OK or Cancel to proceed after entering an input value.
There are rare situations where a page opens multiple dialogs, one after another, when the user clicks a button. Let’s consider the following scenario:
-
When the Submit Data button is clicked, a Prompt dialog is opened for the user to fill-in his/her name.
-
After closing the Prompt dialog with the OK button, when the submit operation is finished, an Alert dialog is displayed.
The Browser Dialog Scope activity can be used to handle this situation by nesting multiple dialog scopes. They have to be arranged in the same order as the dialogs that they handle appear in the page. The workflow will continue once all the dialogs are handled. For the above scenario:
-
First, create a Browser Dialog Scope to handle the first dialog, in this case a Prompt dialog.
-
Inside the first scope, create a second Browser Dialog Scope to handle the second dialog, in this case an Alert dialog.
-
Inside the second scope, place the activity that triggers the dialogs, in this case a click on the Submit Data button.
Besides the Browser Dialog Scope activity, we added browser dialog handling options to the Use Application/Browser activity.
The new Dialog Handling settings in the App Card allow the user to describe how to auto-dismiss browser dialogs (which types of dialogs to dismiss and what response to give to confirm and prompt dialogs).
-
关闭警示
-
Dismiss Confirms + Confirm dialog response
-
Dismiss Prompts + Prompt response text + Prompt dialog response
Similar project settings have been added for Dialog Handling, which work as defaults for the Use Application/Browser Dialog Handling options.
-
Windows项目:用户界面自动化新式 > 应用程序/浏览器
-
跨平台项目:“用户界面自动化” >“应用程序/浏览器”
When multiple Browser Dialog Scope activities and App Cards with Dialog Handling are nested it’s important to keep a few things in mind in order to determine how dialogs will be handled:
-
Browser Dialog Scope activities have priority over the App Card Dialog Handling options.
-
Nested Browser Dialog Scope activities handle multiple dialogs, in the order that they appear: the first Dialog Scope handles the first dialog, the second Dialog Scope handles the second dialog and so on.
-
Nested App Cards with Dialog Handling override each other: the inner App Card will override the settings of the outer App Card. For example, a top-level App Card can be configured to dismiss all dialogs with Cancel throughout the workflow, but for a small part of the workflow a short-lived App Card can used inside the top-level one to accept Confirm dialogs with OK, changing dialog handling only for that part of the workflow. Alerts and Prompts will still be dismissed according to the top-level App Card.
When a browser dialog appears and there are multiple Browser Dialog Scopes and App Cards with Dialog Handling which can handle the dialog, the Browser Dialog Scope or App Card that handles the dialog is selected in the following way:
-
The first (most outer) Browser Dialog Scope activity which: has a matching dialog type and didn't capture any dialog yet.
-
If no Browser Dialog Scope is found, then the last (most inner) App Card which is configured to handle the dialog type is used.
-
If no viable Browser Dialog Scope or App Card is found, then the dialog is not handled and will be displayed to the user.