UI automation goes at its best when Robots and applications run on the same machine because UiPath can integrate directly with the technology behind the application to identify elements, trigger events and get data behind the scenes.
There are three methods UiPath uses for triggering a Click or a Type Into an application. These are displayed as properties in all activities that deal with UI automation.
If SimulateType or SimulateClick are selected, Studio hooks into the application and triggers the event handler of an indicated UI element (button, edit box)
If SendWindowMessages is selected, Studio posts the event details to the application message loop and the application’s window procedure dispatches it to the target UI element internally
Studio signals system drivers with hardware events if none of the above option are selected and lets the operating system dispatch the details towards the target element
These methods should be tried in the order presented, as Simulate and WindowMessages are faster and also work in the background, but they depend mostly on the technology behind the application.
Hardware events work 100% as Studio performs actions just like a human operator (e.g. moving the mouse pointer and clicking at a particular location), but in this case, the application being automated needs to be visible on the screen. This can be seen as a drawback, since there is the risk that the user can interfere with the automation.
Sometimes the automatically generated selectors propose volatile attribute values to identify elements and manual intervention is required to calibrate the selectors. A reliable selector should successfully identify the same element every time in all conditions, in dev, test and production environments and no matter the usernames logged on to the applications.
Here are some tips of how to improve a selector in Selector Editor or UiExplorer:
- Replace attributes with volatile values with attributes that look steady and meaningful
- Replace variable parts of an attribute value with wildcards (*)
- If an attribute’s value is all wildcard (e.g. name=’*’) then attribute should be removed
- If editing attributes doesn’t help, try adding more intermediary containers
- Avoid using idx attribute unless it is a very small number like 1 or 2
In the selector above, we notice the page title has a reference to the time when selector was recorded and also that some attributes have randomly looking IDs. Tweaking the attributes, we can come up with a better selector than UiPath recorder proposed.
Similar to file paths, selectors can be full or partial (relative). Full selectors start with a window or html identifier and have all necessary information to find an element on the whole desktop, while partial selectors work only inside an attach/container that specifies the toplevel window where elements belong:
There are several advantages to using containers with partial selectors instead of full selectors:
- Visually groups activities that work on the same application
- Is slightly faster, not seeking for the top window every time
- Makes it easier to manage top level selectors in case manual updates are necessary
- Essential when working on two instances of the same application