Selectors and UI Automation
How selectors work
A selector is an XML fragment that identifies a UI element by attributes, usually built as a chain of nodes from the application window down to the target. Reliable attributes are stable ones such as id, name, class, tag, aaname, automationid or role. Wildcards * (any characters) and ? (one character) handle titles that contain changing text. Attributes containing counters, timestamps or record names are the classic cause of breakage.
Selectors can be dynamic: embed a variable with {{varName}} or string concatenation so the same activity targets different rows. Anchors and relative selectors find elements by their proximity to a stable neighbour, which rescues you when the target's own attributes are unstable. Also know UI frameworks (Default, Active Accessibility, UI Automation), and targeting methods: Simulate Click / Window Messages are faster and can run in background but fail on some applications, while Hardware Events is the most faithful and the most fragile.
Traps
- Relying on
idxgreater than 1; it changes whenever list order or content changes. - Putting the full window title with a dynamic customer name into a selector.
- Adding every attribute UI Explorer suggests instead of the two or three stable ones.
- Using Default framework where Active Accessibility or UI Automation is required (legacy Java, SAP).
Rule of thumb
Aim for two or three stable attributes and no idx. After building a selector, use Highlight, then Validate, then test it against a second record before you loop.