identify windows
Find all windows matching a definition and assign their physical IDs to variables.
| Name | Description | Type | Modifier |
|---|---|---|---|
| definition | TA name of an interface entity. | Interface Entity | None |
| variable<index> | Names of the variable(s) to receive the returned TA handles. All but the first are optional (Index begins at 1). | String | None |
TA handles
This action may be used within the following project items: test modules and user-defined actions.
This action is applicable to the following controls: window.
definition variable1 variable2 variable3
identify windows login i1 i2 i3
 
window control value
enter # i1 username John
 
window control value
check # i1 username John
 
window control value
enter # i2 password Doe
 
window control value
check # i2 password Doe
 
window control
click # i3 spanish
In the example, you see that each matching window, based on the specified definition, is assigned an unique handle number (identifier) as follows:
- The unique handle number of the first window will be 133132.
- The unique handle number of the second window will be 657472.
- The unique handle number of the third window will be 198728.
- Enter a value to the username control on the matching window, whose handle number is 133132, and then verify the entered value.
- Enter a value to the password control on the matching window, whose handle number is 657472, and then verify the entered value.
- Click the Spanish button to switch to Spanish language on the matching window, whose handle number is 198728.
- Use this action in situations where you want your test to be able to interface with two or more windows to which the same definition (that is, interface entity) applies.
- Subsequent to using this action, a returned TA handle may be used in place of the TA name of an interface entity in the window argument of any action (When working with a variable holding a TA handle, precede it with the expression identifier, #).
- A TA handle is a composite of both the handle returned by the host operating system (hWnd in Windows), and the name of the interface entity definition for that window. The first part allows TestArchitect to uniquely identify a specific window in the system under test, independent of any interface entity definition, so that two or more instances of the same window may be separately addressed by the test actions. The second part allows the window to be associated with an interface entity, thus providing access to the TA names of the window’s controls.
- variable arguments:
- Create as many variable arguments as are required to handle the expected number of instances of the window specified in definition. Note that the headers should be removed from any unused variable arguments.
- If the variables in arguments variable1, variable2, etc have not been declared, the action creates them as globals.
- This action supports the <ignore> modifier. If the string
<ignore>is present as the value of any of the arguments, or any argument contains an expression that evaluates to<ignore>, the action is skipped during execution.
Tel:
Email: