Click |
|
Deprecated For:GenericObject Click | |||||||
CloseWindow |
|
Sends a Close command to the active window. | |||||||
CompareStoredProperties |
|
Deprecated For:GenericObject CompareStoredProperties | |||||||
DoubleClick |
|
Deprecated For:GenericObject DoubleClick | |||||||
GetWinInfo |
|
Gets the value of any property in a window. | |||||||
GoBack |
|
Make the application\device "go back" to the previous state or window. | |||||||
InputCharacters |
|
Deprecated For:GenericMaster InputCharacters | |||||||
InputKeys |
|
Deprecated For:GenericMaster InputKeys | |||||||
Maximize |
|
Sends a WMaximize command to the active window. | |||||||
Minimize |
|
Sends a WMinimize command to the active window. | |||||||
PinchClose |
|
Perform a shrinking "zoom out" operation on a touchscreen device supporting the feature. | |||||||
PinchOpen |
|
Perform an expanding "zoom in" operation on a touchscreen device supporting the feature. | |||||||
Restore |
|
Sends a RestorePos command to the active window. | |||||||
RightClick |
|
Deprecated For:GenericObject RightClick | |||||||
SelectMenuID |
|
Attempts to select a particular menuitem by menuID. | |||||||
SelectMenuItem |
|
Attempts to select a particular text string menuitem. | |||||||
SelectMenuItemContains |
|
Attempts to select a menuitem based on a partial text match. | |||||||
SetFocus |
|
Set focus on the window. | |||||||
SetPosition |
|
Sends a SetPosition command to the window to set the position, size, and status of the window. | |||||||
VerifyImage |
|
Performs a WindowVP CompareImage OR a RegionImageVP on an object. | |||||||
VerifyMainMenu |
|
Compares the active windows menu system with a benchmark | |||||||
VerifyMenuID |
|
Attempts to verify the state information of a particular menuitem identified by MenuID. | |||||||
VerifyMenuItem |
|
Attempts to verify the state information of a particular text string menuitem. | |||||||
VerifyMenuItemContains |
|
Attempts to verify the state information of a menuitem found by partial text match. | |||||||
VerifyOCRValue |
|
Performs an UNLOGGED WindowVP CompareImage OR a RegionImageVP on an object then attempts to retrieve and compare OCR text to the expected value provided. |
WR |
For components that are unrecognized, like ActiveToolbar menuitems, we can click on these or any part of a Window based on a stored x,y coordinate. The window containing the coordinate is first given context and then a 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 Click AnObject
(2) t MainWindow FileMenu Click Exit
#1 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.
#2 above will contain a FileMenu entry in the MainWindow section with normal recognition information for it (the type, however, should still be "Window" even if unspecified). FileMenu will also have it's own section in the Application Map in which there will be an entry like Exit="15,30". This will tell Robot to locate the FileMenu Window object and click at the coordinates specified by the reference.
Name of the AppMap subkey to lookup and use for the click. We expect the AppMap to contain the item in the format "x,y":
[FileMenu] Exit=33,120 OR Exit=Coords=33,120
The results from the lookup are appended to the "Coords=" string used by the Window Click command in Robot (if necessary). So any valid content used with the Window Click command can be part of this AppMap entry.
Both Fields #3 and #5 are used to locate the item in the App Map. This routine does not specify an App Map so only the current Map is used and it is expected to be valid.
RC | RJ | WR | SE | SE2 | TC | AUT |
This Window command has a problem in that it does not want to use the same recognition methods used by the other Window commands (like SetContext). Particularly, it does not accept the Type=Window portion of these recognition methods. In addition, if the window is a child window of a parent then it expects the ";ChildWindow" add-on in the recognition method. The child may also need the parent as part of its full recognition string like:
ChildWindow=Type=Window;<parent rec>;\;Caption=<caption>;ChildWindow
To handle these child windows, we parse the typical recognition method for our window and attempt to handle these issues. Once SetContext has successfully set our window, we then remove any "Type=Window" substring if present and add the ";ChildWindow" substring if not present.
To take advantage of this, this routine must be called with the child window as a component of the parent window like below:
t, ParentWindow, ChildWindow, CloseWindow
If the routine is called like either of the examples below then default processing will occur. This will merely SetContext on the provided Window and use "CurrentWindow" as the parameter to the command.
t, ParentWindow, ParentWindow, CloseWindow
t, ChildWindow , ChildWindow , CloseWindow (normally won't work)
WR |
Performs a WindowVP CompareProperties on an object. The benchmark VP must already exist and be an asset of the currently running script.
To make an existing VP an asset of the current script, the existing script, e.g.,
MADHATTERScript.MyObjectVP.base.OBP
can be copied and renamed to
MyDDScript.MyObjectVP.base.OBP
where MyDDScript is the name of the current script.
The name of the actual VP, MyObjectVP, cannot be altered.
Example 1: Perform a WindowVP on a given window
t, MainWindow, MainWindow, CompareStoredProperties, MainSetupVP1
WR |
For components that are unrecognized, like ActiveToolbar menuitems, we can double click on these or any part of a Window based on a stored x,y coordinate. The window 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 AnObject
(2) t MainWindow FolderTree DoubleClick Node1
#1 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.
#2 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.
Name of the AppMap subkey to lookup and use for the double-click. We expect the AppMap to contain the item in the format "x,y":
[FileMenu] Exit=33,120 OR Exit=Coords=33,120
The results from the lookup are appended to the "Coords=" string used by the Window DBLClick command in Robot (if necessary). So any valid content used with the Window DBLClick command can be part of this AppMap entry.
Both Fields #3 and #5 are used to locate the item in the App Map. This routine does not specify an App Map so only the current Map is used and it is expected to be valid.
WR |
Gets the value of any property in a window and assigns that property to a variable for later use.
DRD |
Depending upon the technology implementation, The WINDOWNAME may not have to be valid or exist at the time of invocation. That is, the WINDOWNAME and COMPNAME fields might not be used and can contain anything.
WR |
WR |
Field 5 : TQ String. case-sensitive text to send to the specified window.
Some Special Characters: {Enter}= ENTER key {Tab} = TAB key ^ = CONTROL Key with another key ( "^S" = CONTROL + s) %= ALT Key with another key ("%F" = ALT + F) + = SHIFT key with another key ("+{Enter}" = SHIFT + ENTER) Currently, we pass-thru to the underlying implementation (Rational SQABasic). Any future implementations will also use the same syntax.
RC | RJ | WR | SE | TC | SE2 | AUT |
Sends a WMaximize command to the active window.
This Window command has a problem in that it does not want to use the same recognition methods used by the other Window commands (like SetContext). Particularly, it does not accept the Type=Window portion of these recognition methods. In addition, if the window is a child window of a parent then it expects the ";ChildWindow" add-on in the recognition method. The child may also need the parent as part of its full recognition string like:
ChildWindow=Type=Window;<parent rec>;\;Caption=<caption>;ChildWindow
To handle these child windows, we parse the typical recognition method for our window and attempt to handle these issues. Once SetContext has successfully set our window, we then remove any "Type=Window" substring if present and add the ";ChildWindow" substring if not present.
To take advantage of this, this routine must be called with the child window as a component of the parent window like below:
t, ParentWindow, ChildWindow, Maximize
If the routine is called like either of the examples below then default processing will occur. This will merely SetContext on the provided Window and use "CurrentWindow" as the parameter to the command.
t, ParentWindow, ParentWindow, Maximize
t, ChildWindow , ChildWindow , Maximize (normally won't work)
RC | RJ | WR | SE | TC | SE2 | AUT |
Sends a WMinimize command to the active window.
This Window command has a problem in that it does not want to use the same recognition methods used by the other Window commands (like SetContext). Particularly, it does not accept the Type=Window portion of these recognition methods. In addition, if the window is a child window of a parent then it expects the ";ChildWindow" add-on in the recognition method. The child may also need the parent as part of its full recognition string like:
ChildWindow=Type=Window;<parent rec>;\;Caption=<caption>;ChildWindow
To handle these child windows, we parse the typical recognition method for our window and attempt to handle these issues. Once SetContext has successfully set our window, we then remove any "Type=Window" substring if present and add the ";ChildWindow" substring if not present.
To take advantage of this, this routine must be called with the child window as a component of the parent window like below:
t, ParentWindow, ChildWindow, Minimize
If the routine is called like either of the examples below then default processing will occur. This will merely SetContext on the provided Window and use "CurrentWindow" as the parameter to the command.
t, ParentWindow, ParentWindow, Minimize
t, ChildWindow , ChildWindow , Minimize (normally won't work)
IOS |
Effectively shrinks a user-defined rectangular area on the screen.
IOS expects the Window/Component to be the main active Window of the application.
We expect the rectangle stored in the App Map or the literal text to be specified as integer rectangle coordinates and size in pixels: X,Y,Width,Height.
[AppWindow] ... Origin1="50,200,25,25" OR Origin2="Coords=100,75,125,125" ...
Engines should attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:
If the App Map does not contain the subkey item then the engines should assume the value is the literal text of the rectangle coordinate and size values.
We expect the resize value stored in the App Map or the literal text to be specified as integer values (in pixels): +/-Width, +/-Height.
[AppWindow] ... Resize1="0,-50" (no width change, but shrink the height by 50 pixels) Resize2="Coords=-40,0" (shrink width by 40 pixels, with no change in height.) ...
These resize offsets can be positive or negative integer values and will be added to the existing width and/or height of OrigRect.
Engines should attempt to support values separated by alternate separators. The most common separators that should be supported would be:
If the App Map does not contain the subkey item then the engines should assume the value is the literal text of the resize values.
IOS |
Effectively expands or stretches a user-defined rectangular area on the screen.
IOS expects the Window/Component to be the main active Window of the application.
We expect the rectangle stored in the App Map or the literal text to be specified as integer rectangle coordinates and size in pixels: X,Y,Width,Height.
[AppWindow] ... Origin1="50,200,25,25" OR Origin2="Coords=100,75,125,125" ...
Engines should attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:
If the App Map does not contain the subkey item then the engines should assume the value is the literal text of the rectangle coordinate and size values.
We expect the resize value stored in the App Map or the literal text to be specified as integer values (in pixels): +/-Width, +/-Height.
[AppWindow] ... Resize1="0,50" (no width change, but grow in height by 50 pixels) Resize2="Coords=50,0" (grow width by 50 pixels, with no change in height.) ...
These resize offsets can be positive or negative integer values and will be added to the existing width and/or height of OrigRect.
Engines should attempt to support values separated by alternate separators. The most common separators that should be supported would be:
If the App Map does not contain the subkey item then the engines should assume the value is the literal text of the resize values.
RC | RJ | WR | SE | TC | SE2 | AUT |
Sends a RestorePos command to the active window.
This Window command has a problem in that it does not want to use the same recognition methods used by the other Window commands (like SetContext). Particularly, it does not accept the Type=Window portion of these recognition methods. In addition, if the window is a child window of a parent then it expects the ";ChildWindow" add-on in the recognition method. The child may also need the parent as part of its full recognition string like:
ChildWindow=Type=Window;<parent rec>;\;Caption=<caption>;ChildWindow
To handle these child windows, we parse the typical recognition method for our window and attempt to handle these issues. Once SetContext has successfully set our window, we then remove any "Type=Window" substring if present and add the ";ChildWindow" substring if not present.
To take advantage of this, this routine must be called with the child window as a component of the parent window like below:
t, ParentWindow, ChildWindow, Restore
If the routine is called like either of the examples below then default processing will occur. This will merely SetContext on the provided Window and use "CurrentWindow" as the parameter to the command.
t, ParentWindow, ParentWindow, Restore
t, ChildWindow , ChildWindow , Restore (normally won't work)
WR |
For components that are unrecognized, like ActiveToolbar menuitems, we can right click on these or any part of a Window based on a stored x,y coordinate. The window 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 AnObject
(2) t MainWindow ToolItem RightClick PrintTool
#1 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.
#2 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.
Name of the AppMap subkey to lookup and use for the right-click. We expect the AppMap to contain the item in the format "x,y":
[FileMenu] Exit=33,120 OR Exit=Coords=33,120
The results from the lookup are appended to the "Coords=" string used by the Window Right_Click command in Robot (if necessary). So any valid content used with the Window Right_Click command can be part of this AppMap entry.
Both Fields #3 and #5 are used to locate the item in the App Map. This routine does not specify an App Map so only the current Map is used and it is expected to be valid.
RC | WR |
RC | RJ | WR |
Attempts to select a particular text string menuitem. The menuitem should be specified in the form "Menu->Menu->MenuItem CTRL+V" with the full text, spaces(if any), and keyboard shortcut text (if any).
Ampersands preceding underlined characters are optional. The routine first verifies that the specified menuitem exists and exits with error if it does not. If it does exist then the selection proceeds using the MenuID retrieved from the found menuitem.
RC | RJ | WR |
Attempts to select a menuitem based on a partial text match. The menuitem should be specified in the form "Menu->Menu->MenuItem". Each level in the hierarchy can be represented by partial text.
Ampersands preceding underlined characters are optional. The routine first verifies that the specified menuitem exists and exits with error if it does not. If it does exist then the selection proceeds using the MenuID retrieved from the found menuitem.
SE |
Set focus and bring the window forward.
Bring the window forward. If there are same name/caption/title windows then the first window will come forward. The window is find by title.
RC | RJ | WR | SE | TC | SE2 | AUT |
Sends a SetPosition command to the window to set the position, size, and status of the window. The position, size, and status information is stored in the app map as a subitem in the section for the window. The information should be in the format of:
"0,0,640,480;Status=NORMAL" OR "Coords=0,0,640,480;Status=NORMAL"
That example positions the window at 0,0; sizes it to 640 x 480, and sets it's status to NORMAL. Valid values for STATUS are:
NORMAL, MINIMIZED, and MAXIMIZED
The Window SetPosition command has a problem in that it does not want to use the same recognition methods used by the other Window commands (like SetContext). Particularly, it does not accept the Type=Window portion of these recognition methods. In addition, if the window is a child window of a parent then it expects the ";ChildWindow" add-on in the recognition method. The child may also need the parent as part of its full recognition string like:
ChildWindow=Type=Window;<parent rec>;\;Caption=<caption>;ChildWindow
To handle these child windows, we parse the typical recognition method for our window and attempt to handle these issues. Once SetContext has successfully set our window, we then remove any "Type=Window" substring if present and add the ";ChildWindow" substring if not present.
To take advantage of this, this routine must be called with the child window as a component of the parent window like below:
t, ParentWindow, ChildWindow, SetPosition, ChildPositionReference
If the routine is called like either of the examples below then default processing will occur. This will merely SetContext on the provided Window and use "CurrentWindow" as the parameter to SetPosition.
t, ParentWindow, ParentWindow, SetPosition, ParentPosition
t, ChildWindow , ChildWindow , SetPosition, ChildPosition (normally won't work)
RC | WR |
Performs a WindowVP CompareImage OR a RegionImageVP on an object. The benchmark VP must already exist and be an asset of the currently running script.
A RegionImageVP can be accomplished by having the name of the VP as an item under the component in the application map. The item's value must be the coordinate values required by the RegionImageVP (i.e. "65,100,200,250").
Example 1: Perform a WindowVP CompareImage
MainWindow SomeWindowObject VerifyImage StoredVP
(no StoredVP item found in the app map under SomeWindowObject)
The named VP (StoredVP) must not exist in the application map. The entire panel/object of SomeWindowObject will be captured and compared against the StoredVP baseline which must already exist as an asset of the currently running script.
Example 2: Perform a RegionImageVP on a particular area of the screen
MainWindow SomeWindowObject VerifyImage StoredVP
(StoredVP found as:
"65,100,200,250" OR "Coords=65,100,200,250"
in the SomeWindowObject section of the app map)
The named VP (StoredVP) is found to exist in the application map as a subitem in the SomeWindowObject section of the map. This causes the routine to attempt a RegionImageVP using the map's value of the StoredVP item as the coordinates for the region to capture. StoredVP is ALSO the name of the VP which must already exist as an asset of the currently running script.
RC | WR |
RC | WR |
Field 5 : TQ String. the full case-sensitive menu item path to select. Ampersands (&) indicating/preceding underlined characters are optional. The text must include the full text including spaces and any visible shortcut key combinations displayed in the text of the menu item.
Field 6 : QS String. The case-sensitive, space-delimited, double-quote enclosed status information needing verification. Only the state information of interest needs to be specified.
RC | RJ | WR |
Note 1: This command differs from JavaMenuFunctions.VerifyMenuItemContains as this command seeks a Window object that contains a Window's menu.
Note 2: For RobotJ engine, this command only supports JavaSwing. It may support other clients in the future.
Field 5 : TQ String. the full case-sensitive menu item path to select. Ampersands (&) indicating/preceding underlined characters are optional. The text must include the full text including spaces and any visible shortcut key combinations displayed in the text of the menu item.
Field 6 : QS String. The case-sensitive, space-delimited, double-quote enclosed status information needing verification. Only the state information of interest needs to be specified.
RC | RJ | WR |
Note 1: This command differs from JavaMenuFunctions.VerifyMenuItemContains as this command seeks a Window object that contains a Window's menu.
Note 2: For RobotJ engine, this command only supports JavaSwing. It may support other clients in the future.
Field 5 : TQ String. the case-sensitive menu item path to select. Ampersands (&) indicating/preceding underlined characters are optional. The text can be any substring of the full text including spaces and any visible shortcut key combinations displayed in the text of the menu item.
Field 6 : QS String. The case-sensitive, space-delimited, double-quote enclosed status information needing verification. Only the state information of interest needs to be specified.
RC | WR |
Performs an UNLOGGED WindowVP CompareImage OR a RegionImageVP on an object then attempts to retrieve and compare OCR text to the expected value provided. The benchmark VP must already exist and be an asset of the currently running script.
A RegionImageVP can be accomplished by having the name of the VP as an item under the component in the application map. The item's value must be the coordinate values required by the RegionImageVP (i.e. "Coords=65,100,200,250").
EXAMPLE 1 : Perform a WindowVP CompareImage before OCR Test
t, MainWindow, SomeWindowObject, VerifyOCRValue, StoredVP, 1, "Expected Text"
(no StoredVP item found in the app map under SomeWindowObject)
The named VP (StoredVP) must not exist in the application map if you intend to compare the entire window. The entire panel/object of SomeWindowObject will be captured and compared against the StoredVP baseline. This VP must already exist as an asset of the currently running script.
EXAMPLE 2 : Perform a RegionImageVP before the OCR test
t, MainWindow, SomeWindowObject, VerifyOCRValue, StoredVP, DataField, "Expected Text"
StoredVP found in Application Map like below:
[SomeWindowObject] SomeWindowObject="Type=Something...." StoredVP="Coords=65,100,200,250" --- invokes a RegionImageVP ....
When the named VP (StoredVP) is found to exist in the application map as a subitem in the SomeWindowObject section of the map then a RegionImageVP will be invoked using the value of the StoredVP item as the coordinates for the region to capture.
StoredVP is ALSO the name of the VP which must already exist as an asset of the currently running script.
Once the unlogged VP has been completed, we attempt to retrieve the text of a predefined OCR region mask that should exist in the VP.
We can use the OCRRegion value provided from the inputrecord to identify the OCR mask number as needed by the SQAGetOcrRegionText function in Robot. Example 1 above shows we are looking for OCR region #1.
The OCRRegion value in the inputrecord can also be a reference in the Application Map in a section with the same name as the VP as shown below.
[SomeWindowObject] SomeWindowObject="Type=Something...." StoredVP="Coords=65,100,200,250" ....
[StoredVP] DataField=1 AnotherField=2 ....
Example 2 above shows that we have given region #1 a name of DataField.
Once retrieved, the OCR text (if any) is compared against the expected results provided.
The name of a stored VP which must exist as an asset of the currently running script. Normally, a straight Robot CompareImage of the entire Window would be performed. However, if the AStoredVP value given exists in the Application Map as a reference under the provided Window object then a RegionImage test will be attempted instead.
The Numeric OCR region Number of the particular OCR text you are trying to compare. Valid values can be found when viewing the CompareImage or RegionImageVP baseline. A number can be used directly or a named reference can be used if it is found to exist in the Application Map in a Section with the same name as the VP.
The expected value of the text we wish to compare against the retrieved OCR text.