LESSON 6 – SELECTORS - RECAP

Overview

In this chapter we addressed one of the most important parts in UiPath automation: selectors.
These xml strings contain properties that uniquely define a specified element.
Takeaways
Interfaces are built by using containers, nested one inside the other

You can think of a selector as a path to the required UI element, starting from the
root container and all the way to our target

A selector contains 2 types of information: the element type and one or more of
its attributes.

When automatically building a selector, UiPath tries to use only the first and last
container but it also adds intermediate ones only needed

Selectors should be constructed in such a way that they point to only one element
in the environment. If a robot finds multiple possible matches for a selector, it uses
the first one it encounters – usually the topmost one
Takeaways
Basic recording generates full selectors while Desktop recording
generates only partial ones.

You can build dynamic selectors using the 2 available wildcards: question
mark (?) takes the place of a single character and asterisk (*) that replaces any
number of characters or by using variables.

Use Attach to live element to update an existing selector to also match a 2nd
element.

Use the selector’s idx property to get a certain occurrence of an element that is
found multiple times.

Anchor Base activity and Select Relative Element in UiEplorer can be very useful to
build reliable automations when the selectors might not be very stable.
Best practices

Avoid using the idx attribute if its value is larger than 2, unless you don’t have other
options. Always try to add other attributes to make sure the selector is stable.

When it’s likely that you will have interference from other applications and windows
it’s best to use partial selectors.
Useful