Object Studio and Application Modelling
Building objects
Object Studio is where you model an application and expose Actions. The workflow is: launch or attach to the application, create an Application Model capturing the window and its elements, then build Action pages that use Read, Write, Navigate, Wait, and Press stages against modelled elements. Application models can be nested: a parent window model contains child elements and sub-models for dialogs or frames.
Spy modes matter. Win32 mode is fast and reliable for standard Windows controls; Accessibility mode suits controls that Win32 cannot see and is often better for Java or older frameworks; UIAutomation and Browser modes handle modern and web applications with richer element attributes; Region mode is a last resort using image matching and is the least robust. Choose the most specific, most stable mode available.
Traps in questions
- Region/image matching is fragile to resolution, theme, and occlusion - questions reward avoiding it when a proper mode exists.
- Attributes used for matching must be stable; dynamic text such as a row count or timestamp should not be a match attribute.
- Wait stages should poll for a condition rather than use a fixed delay.
- An Action must have defined Inputs and Outputs; returning values through session variables instead is poor practice.
- Attaching to an already-open application versus launching a new instance changes behaviour on shared desktops.
Rule of thumb
Model what is stable and identify what changes. Prefer element attributes over screen coordinates, and always wrap application interaction so a changed screen breaks one Action, not fifty processes.
Worked example
A grid's row count appears in a window title, so a candidate matches on the title. Wrong: the count changes. Correct: match on the static window caption and read the row count as data, or match rows by a stable key attribute.