We can also ALT-click on any part of an object based on a stored x,y coordinate. The object containing the coordinate is first given context and then a ALT-click is generated at the coordinate. Thus, an item or object can be referenced by name even though it is only recognized via coordinates.

The coordinate lookup is done with the component name of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow MainWindow AltClick
(2) t MainWindow MainWindow AltClick AnObject
(3) t MainWindow ToolItem AltClick PrintTool

#2 above will contain an AnObject="3,10" entry in the MainWindow section of the Application Map to ALT-click at x=3, y=10 in the MainWindow. For SE+, the coordinate can be percentage format, like "20%,30%". This percentage format indicates the point (20% width of component, 30% height of component) relative to the object.

#3 above will contain a ToolItem entry in the MainWindow section with normal recognition information for it . ToolItem will also have it's own section in the Application Map in which there will be an entry like PrintTool="15,30". This will tell Robot to locate the PrintTool Window object and ALT-click at the coordinates specified by the reference.

Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:

• "," (comma) Example: "50,200"
• ";" (semi-colon) Example: "50;200"
• " " (space) Example: "50 200"

The coordinate lookup is done with the component name(Field #3) of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow GenericItem AltLeftDrag DragName

#1 above will contain a GenericItem entry in the MainWindow section with normal recognition information for it . GenericItem will also have it's own section in the Application Map in which there will be an entry like:

DragName="15,30,60,90" OR DragName="Coords=15,30,60,90"

This will tell RFT to locate the GenericItem Window object and an ALT left mouse drag from coordinates 15,30 to 60,90.

By default, clicks on the center of the component. We can also click on any part of an object, or any point relative to an object based on a provided x,y coordinate or other component-specific parameters.

For SE+, the coordinate can be percentage format, like "20%,30%". This percentage format indicates the point (20% width of component, 30% height of component) relative to the object.

The object to be clicked is first given context and then a click is generated at the coordinates. Thus, a subitem or object can be referenced by name even though it is only recognized via coordinates.

The coordinate lookup is done with the component name of the record AND Field #5 or by providing the literal text of the coordinates, where supported.

Typical Data Table records:

(1) t MainWindow MainWindow Click
(2) t MainWindow MainWindow Click AnObject
(3) t MainWindow FolderTree Click Node1
(4) t MainWindow MainWindow Click "50,200"
(5) t MainWindow MainWindow Click "Coords=50,200"

For SE+, the Data Table records can be:

(6) t MainWindow MainWindow Click "50%,20%"
(7) t MainWindow MainWindow Click "50,20%"

#2 above will contain an AnObject="3,10" entry in the MainWindow section of the Application Map to click at x=3, y=10 in the MainWindow.

#3 above will contain a FolderTree entry in the MainWindow section with normal recognition information for it. FolderTree will also have it's own section in the Application Map in which there will be an entry like Node1="15,30". This will tell Robot to locate the FolderTree Generic object and click at the coordinates specified by the reference.

#4 and #5 above show using literal text instead of an App Map entry to specify where to click relative to the item.

#6 and #7 above show using percentage format in SE+. #6 will click at position, where the X value equals 50% width of component, its Y value equals 20% height of component, relative to the object. #7 will click at position, where the X value equals 50, its Y value equals 20% height of component, relative to the object.

Rational Robot no longer requires the AppMapSubKey be provided and will attempt to use the string as literal text if no AppMapSubKey is found in the current App Map. Robot also no longer assumes the AppMapSubKey value or the literal value is presenting coordinate information. This allows components that can accept parameters other than coordinates, like table row/col values or ImageMap areas to be specified.

If the value is deduced to contain coordinates, but is not prefixed with "Coords=" text, then Robot will add the prefix. Otherwise, the text value will remain unmodified.

This is the direction we expect all tools to follow going forward.

Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:

• "," (comma) Example: "50,200"
• ";" (semi-colon) Example: "50;200"
• " " (space) Example: "50 200"

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

For IOS: Any optional coordinates MUST be specified as an integer number between 0-100. 0 represents the extreme left (or top), while 100 represents the extreme right (or bottom). IOS does not use absolute coordinates, but relative coordinates representing a percentage of the element width or height.

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

We can click on any screen location based on stored x,y coordinates or hardcoded literal values. The Window:Component fields can be anything at all and will be ignored if they do not exist in the app map, or if the retrieved app map data does not contain coordinate data. Thus, an item or object can be referenced by name even though it is only known via coordinates.

If the Window:Component AppMap lookup does NOT contain coordinate data and is ignored, then the AppMapSubKey field is REQUIRED and is expected to contain a reference or literal text containing absolute screen coordinates.

If the Window:Component AppMap lookup DOES contain coordinate data, this data is treated as the absolute screen coordinates to be used. The AppMapSubKey field becomes OPTIONAL and coordinate data in the field is treated as a relative offset added to the absolute values found for the Window:Component.

Any AppMapSubKey lookup is done with the Component name in the record AND Field #5.

Typical Data Table records:

(1) t MainWindow Component ClickScreenLocation
(2) t MainWindow MainWindow ClickScreenLocation AnObject
(3) t MainWindow MainWindow ClickScreenLocation 50,80
(4) t AnyWin AnyComp ClickScreenLocation Node1

#1 above will contain a blank as it's 5th field. Because the AppMapSubKey field is blank, the [MainWindow] section of the AppMap MUST have a Component item with valid absolute screen coordinates for the click.

#2 above will contain an AnObject="Coords=50,80" entry in the [MainWindow] section of the AppMap. If there is a MainWindow component in the AppMap with valid screen coordinates then the click will occur with a relative offset of 50,80 from those absolute screen coordinates. Otherwise, the click will occur at absolute screen coordinates 50,80.

#3 If there is a MainWindow component in the [MainWindow] section of the AppMap with valid screen coordinates then the click will occur with a relative offset of 50,80 from those absolute screen coordinates. Otherwise, the click will occur at absolute screen coordinates 50,80.

#4 above will contain no valid AnyWin:AnyComp coordinate data and those fields will be ignored. However, Node1 MUST exist in the Application Map [AnyComp] section to provide absolute screen coordinates for the click.

We can click on any screen location based on literal text x,y coordinates retrieved from Field #5. Window and Component names and App Map entries are completely ignored. So the user can put anything in those fields that might help test readability.

It is not recommended to hardcode screen coordinates in the test table in this way.

The coordinate lookup is done with the component name(Field #3) of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow GenericItem CtrlAltLeftDrag DragName

#1 above will contain a GenericItem entry in the MainWindow section with normal recognition information for it . GenericItem will also have it's own section in the Application Map in which there will be an entry like:

DragName="15,30,60,90" OR DragName="Coords=15,30,60,90"

This will tell RFT to locate the GenericItem Window object and CTRL ALT left mouse drag from coordinates 15,30 to 60,90.

We can also CTRL-click on any part of an object based on a stored x,y coordinate. The object containing the coordinate is first given context and then a CTRL-click is generated at the coordinate. Thus, an item or object can be referenced by name even though it is only recognized via coordinates.

The coordinate lookup is done with the component name of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow MainWindow CtrlClick
(2) t MainWindow MainWindow CtrlClick AnObject
(3) t MainWindow ToolItem CtrlClick PrintTool

#2 above will contain an AnObject="3,10" entry in the MainWindow section of the Application Map to CTRL-click at x=3, y=10 in the MainWindow. For SE+, the coordinate can be percentage format, like "20%,30%". This percentage format indicates the point (20% width of component, 30% height of component) relative to the object.

#3 above will contain a ToolItem entry in the MainWindow section with normal recognition information for it . ToolItem will also have it's own section in the Application Map in which there will be an entry like PrintTool="15,30". This will tell Robot to locate the PrintTool Window object and CTRL-click at the coordinates specified by the reference.

Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:

• "," (comma) Example: "50,200"
• ";" (semi-colon) Example: "50;200"
• " " (space) Example: "50 200"

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

The coordinate lookup is done with the component name(Field #3) of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow GenericItem CtrlLeftDrag DragName

#1 above will contain a GenericItem entry in the MainWindow section with normal recognition information for it . GenericItem will also have it's own section in the Application Map in which there will be an entry like:

DragName="15,30,60,90" OR DragName="Coords=15,30,60,90"

This will tell RFT to locate the GenericItem Window object and CTRL left drag from coordinates 15,30 to 60,90.

We can also CTRL-Right-Click on any part of an object based on a stored x,y coordinate. The object containing the coordinate is first given context and then a CTRL-Right-Click is generated at the coordinate. Thus, an item or object can be referenced by name even though it is only recognized via coordinates.

The coordinate lookup is done with the component name of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow MainWindow CtrlRightClick
(2) t MainWindow MainWindow CtrlRightClick AnObject
(3) t MainWindow ToolItem CtrlRightClick PrintTool

#2 above will contain an AnObject="3,10" entry in the MainWindow section of the Application Map to CTRL-click at x=3, y=10 in the MainWindow. For SE+, the coordinate can be percentage format, like "20%,30%". This percentage format indicates the point (20% width of component, 30% height of component) relative to the object.

#3 above will contain a ToolItem entry in the MainWindow section with normal recognition information for it . ToolItem will also have it's own section in the Application Map in which there will be an entry like PrintTool="15,30". This will tell Robot to locate the PrintTool Window object and CTRL-Right-Click at the coordinates specified by the reference.

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

The coordinate lookup is done with the component name(Field #3) of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow GenericItem CtrlShiftLeftDrag DragName

#1 above will contain a GenericItem entry in the MainWindow section with normal recognition information for it . GenericItem will also have it's own section in the Application Map in which there will be an entry like:

DragName="15,30,60,90" OR DragName="Coords=15,30,60,90"

This will tell RFT to locate the GenericItem Window object and CTRL SHIFT left mouse drag from coordinates 15,30 to 60,90.

We can also double click on any part of an object based on a stored x,y coordinate. The object containing the coordinate is first given context and then a double click is generated at the coordinate. Thus, an item or object can be referenced by name even though it is only recognized via coordinates.

The coordinate lookup is done with the component name of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow MainWindow DoubleClick
(2) t MainWindow MainWindow DoubleClick AnObject
(3) t MainWindow FolderTree DoubleClick Node1

#2 above will contain an AnObject="3,10" entry in the MainWindow section of the Application Map to double click at x=3, y=10 in the MainWindow. For SE+, the coordinate can be percentage format, like "20%,30%". This percentage format indicates the point (20% width of component, 30% height of component) relative to the object.

#3 above will contain a FolderTree entry in the MainWindow section with normal recognition information for it . FolderTree will also have it's own section in the Application Map in which there will be an entry like Node1="15,30". This will tell Robot to locate the FolderTree object and double click at the coordinates specified by the reference.

Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:

• "," (comma) Example: "50,200"
• ";" (semi-colon) Example: "50;200"
• " " (space) Example: "50 200"

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

For IOS: Any optional coordinates MUST be specified as an integer number between 0-100. 0 represents the extreme left (or top), while 100 represents the extreme right (or bottom). IOS does not use absolute coordinates, but relative coordinates representing a percentage of the element width or height.

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

We can click on any screen location based on stored x,y coordinates or hardcoded literal values. The Window:Component fields can be anything at all and will be ignored if they do not exist in the app map, or if the retrieved app map data does not contain coordinate data. Thus, an item or object can be referenced by name even though it is only known via coordinates.

If the Window:Component AppMap lookup does NOT contain coordinate data and is ignored, then the AppMapSubKey field is REQUIRED and is expected to contain a reference or literal text containing absolute screen coordinates.

If the Window:Component AppMap lookup DOES contain coordinate data, this data is treated as the absolute screen coordinates to be used. The AppMapSubKey field becomes OPTIONAL and coordinate data in the field is treated as a relative offset added to the absolute values found for the Window:Component.

Any AppMapSubKey lookup is done with the Component name in the record AND Field #5.

Typical Data Table records:

(1) t MainWindow Component DoubleClickScreenLocation
(2) t MainWindow MainWindow DoubleClickScreenLocation AnObject
(3) t MainWindow MainWindow DoubleClickScreenLocation 50,80
(4) t AnyWin AnyComp DoubleClickScreenLocation Node1

#1 above will contain a blank as it's 5th field. Because the AppMapSubKey field is blank, the [MainWindow] section of the AppMap MUST have a Component item with valid absolute screen coordinates for the click.

#2 above will contain an AnObject="Coords=50,80" entry in the [MainWindow] section of the AppMap. If there is a MainWindow component in the AppMap with valid screen coordinates then the click will occur with a relative offset of 50,80 from those absolute screen coordinates. Otherwise, the click will occur at absolute screen coordinates 50,80.

#3 If there is a MainWindow component in the [MainWindow] section of the AppMap with valid screen coordinates then the click will occur with a relative offset of 50,80 from those absolute screen coordinates. Otherwise, the click will occur at absolute screen coordinates 50,80.

#4 above will contain no valid AnyWin:AnyComp coordinate data and those fields will be ignored. However, Node1 MUST exist in the Application Map [AnyComp] section to provide absolute screen coordinates for the click.

We can click on any screen location based on literal text x,y coordinates retrieved from Field #5. Window and Component names and App Map entries are completely ignored. So the user can put anything in those fields that might help test readability.

It is not recommended to hardcode screen coordinates in the test table in this way.

Drag will be performed from component (from-component) to another to-component. Offsets value are the drag object select location. The location (drag and release) calucate by X and Y percentage cordination. DragTo also supports sub item of component and sub item of to-component.

The coordination specify by offsets value. First two values are for from-component and another are for to-component.

For components that are unrecognized, we can make a mouse drag in these to draw fields(rectangles) or do drag and drop, based on stored x,y start and end coordinates. The object containing the starting coordinates is first given context and then a left mouse drag is performed with the stored coordinates.

The coordinate lookup is done with the component name(Field #3) of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow GenericItem LeftDrag DragName

#1 above will contain a GenericItem entry in the MainWindow section with normal recognition information for it . GenericItem will also have it's own section in the Application Map in which there will be an entry like:

                DragName="15,30,60,90"    OR
                DragName="Coords=15,30,60,90"
                

This will tell Robot to locate the GenericItem Window object and left drag from coordinates 15,30 to 60,90.

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

By default, clicks on the center of the component 3 times.
Use the optional ClickCount parameter to specify the desired number of clicks.
We can also click on any part of an object, or any point relative to an object based on a provided x,y coordinate or other component-specific parameters.

The object to be clicked is first given context and then the clicks are generated at the coordinates. Thus, a subitem or object can be referenced by name even though it is only recognized via coordinates.

The optional coordinate lookup is done with the component name of the record AND Field #5 or by providing the literal text of the coordinates, where supported.

Typical Data Table records with relative references:

(1) t MainWindow MainWindow MultiClick
(2) t MainWindow MainWindow MultiClick AnObject
(3) t MainWindow FolderTree MultiClick Node1 "4"
(4) t MainWindow MainWindow MultiClick "50,200" "3"
(5) t MainWindow MainWindow MultiClick "Coords=50,200" "2"

#1 above should click 3 times (default) at the center (default) of the MainWindow.

#2 above will contain an AnObject="3,10" entry in the MainWindow section of the Application Map to click 3 times (default) at x=3, y=10 in the MainWindow.

#3 above will contain a FolderTree entry in the MainWindow section with normal recognition information for it. FolderTree will also have it's own section in the Application Map in which there will be an entry like Node1="15,30". This will tell the runtime to locate the FolderTree Generic object and click 3 times (default) at the coordinates specified by the reference.

#4 and #5 above show using literal text instead of an App Map entry to specify where to click relative to the item. The item will be clicked 3 times and 2 times, respectively

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

We can also right click on any part of an object based on a stored x,y coordinate. The object containing the coordinate is first given context and then a right click is generated at the coordinate. Thus, an item or object can be referenced by name even though it is only recognized via coordinates.

The coordinate lookup is done with the component name of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow MainWindow RightClick
(2) t MainWindow MainWindow RightClick AnObject
(3) t MainWindow ToolItem RightClick PrintTool

#2 above will contain an AnObject="3,10" entry in the MainWindow section of the Application Map to right click at x=3, y=10 in the MainWindow. For SE+, the coordinate can be percentage format, like "20%,30%". This percentage format indicates the point (20% width of component, 30% height of component) relative to the object.

#3 above will contain a ToolItem entry in the MainWindow section with normal recognition information for it . ToolItem will also have it's own section in the Application Map in which there will be an entry like PrintTool="15,30". This will tell Robot to locate the PrintTool Window object and right click at the coordinates specified by the reference.

Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:

• "," (comma) Example: "50,200"
• ";" (semi-colon) Example: "50;200"
• " " (space) Example: "50 200"

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

We can click on any screen location based on stored x,y coordinates or hardcoded literal values. The Window:Component fields can be anything at all and will be ignored if they do not exist in the app map, or if the retrieved app map data does not contain coordinate data. Thus, an item or object can be referenced by name even though it is only known via coordinates.

If the Window:Component AppMap lookup does NOT contain coordinate data and is ignored, then the AppMapSubKey field is REQUIRED and is expected to contain a reference or literal text containing absolute screen coordinates.

If the Window:Component AppMap lookup DOES contain coordinate data, this data is treated as the absolute screen coordinates to be used. The AppMapSubKey field becomes OPTIONAL and coordinate data in the field is treated as a relative offset added to the absolute values found for the Window:Component.

Any AppMapSubKey lookup is done with the Component name in the record AND Field #5.

Typical Data Table records:

(1) t MainWindow Component RightClickScreenLocation
(2) t MainWindow MainWindow RightClickScreenLocation AnObject
(3) t MainWindow MainWindow RightClickScreenLocation 50,80
(4) t AnyWin AnyComp RightClickScreenLocation Node1

#1 above will contain a blank as it's 5th field. Because the AppMapSubKey field is blank, the [MainWindow] section of the AppMap MUST have a Component item with valid absolute screen coordinates for the click.

#2 above will contain an AnObject="Coords=50,80" entry in the [MainWindow] section of the AppMap. If there is a MainWindow component in the AppMap with valid screen coordinates then the click will occur with a relative offset of 50,80 from those absolute screen coordinates. Otherwise, the click will occur at absolute screen coordinates 50,80.

#3 If there is a MainWindow component in the [MainWindow] section of the AppMap with valid screen coordinates then the click will occur with a relative offset of 50,80 from those absolute screen coordinates. Otherwise, the click will occur at absolute screen coordinates 50,80.

#4 above will contain no valid AnyWin:AnyComp coordinate data and those fields will be ignored. However, Node1 MUST exist in the Application Map [AnyComp] section to provide absolute screen coordinates for the click.

We can click on any screen location based on literal text x,y coordinates retrieved from Field #5. Window and Component names and App Map entries are completely ignored. So the user can put anything in those fields that might help test readability.

It is not recommended to hardcode screen coordinates in the test table in this way.

For components that are unrecognized, we can make a mouse drag in these to draw fields(rectangles) or do drag and drop, based on stored x,y start and end coordinates. The object containing the starting coordinates is first given context and then a right mouse drag is performed with the stored coordinates.

The coordinate lookup is done with the component name(Field #3) of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow GenericItem RightDrag DragName

#1 above will contain a GenericItem entry in the MainWindow section with normal recognition information for it . GenericItem will also have it's own section in the Application Map in which there will be an entry like:

DragName="15,30,60,90" OR DragName="Coords=15,30,60,90"

This will tell Robot to locate the GenericItem Window object and right drag from coordinates 15,30 to 60,90.

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

We can SHIFT click on any part of an object based on a stored x,y coordinate. The object containing the coordinate is first given context and then a SHIFT click is generated at the coordinate. Thus, an item or object can be referenced by name even though it is only recognized via coordinates.

The coordinate lookup is done with the component name of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow MainWindow ShiftClick
(2) t MainWindow MainWindow ShiftClick AnObject
(3) t MainWindow ToolItem ShiftClick PrintTool

#2 above will contain an AnObject="3,10" entry in the MainWindow section of the Application Map to SHIFT click at x=3, y=10 in the MainWindow. For SE+, the coordinate can be percentage format, like "20%,30%". This percentage format indicates the point (20% width of component, 30% height of component) relative to the object.

#3 above will contain a ToolItem entry in the MainWindow section with normal recognition information for it . ToolItem will also have it's own section in the Application Map in which there will be an entry like PrintTool="15,30". This will tell Robot to locate the PrintTool Window object and SHIFT click at the coordinates specified by the reference.

Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:

• "," (comma) Example: "50,200"
• ";" (semi-colon) Example: "50;200"
• " " (space) Example: "50 200"

Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.

The coordinate lookup is done with the component name(Field #3) of the record AND Field #5.

Typical Data Table records:

(1) t MainWindow GenericItem ShiftLeftDrag DragName

#1 above will contain a GenericItem entry in the MainWindow section with normal recognition information for it . GenericItem will also have it's own section in the Application Map in which there will be an entry like:

DragName="15,30,60,90" OR DragName="Coords=15,30,60,90"

This will tell RFT to locate the GenericItem Window object and SHIFT left drag from coordinates 15,30 to 60,90.