SAFS Dynamic Engine Reference
(updated )The following reference material is in a format similar to an outline. When you click on an item it will expand (or collapse) to show or hide the information available within that section. Here you will find links to sample files, available commands for the engine and GUI components, and the syntax for these commands. In general, an empty circle will signify the item does not expand (but it may contain a link to another document), while a solid disk or square indicates the item does expand (or collapse).
Test Automation Frameworks Whitepaper for information on various forms of test automation and, specifically, the data-driven or keyword-driven form of SAFS test automation.
Reference:
SDC | TID |
SDC | TID |
RJ | TID | SDC | SE2 | DRD |
RJ | TID | SDC | SE2 |
The variables varName.RC and varName.RESULT are defined on completion of the command.
RJ | SDC | TID | TC | SE2 |
RC | RJ | SDC | SE2 |
RJ | SE | SE2 | TC | DRD |
SDC | SE2 |
RC | RJ | TID | SDC | SE2 | WR | DRD |
DRD | RC | RJ | IOS | TID | SDC | SE2 | WR |
TID | SE2 |
RC | RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
RJ |
Domain names should not be case-sensitive.
RJ |
Domain names should not be case-sensitive.
RC | TID | SE2 |
SDC | SE2 |
RC | RJ | TC |
RC | TC |
Variable name to receive the newly formatted date.
TID |
RJ | SDC | TID | SE2 |
RJ |
RJ |
RJ |
RJ |
RJ |
RC | RJ | TID | SDC | WR | SE2 |
RC | RJ | TID | SDC | WR | SE2 |
RC | RJ | TID | SDC | WR | SE2 |
SE2 |
RJ | TID | SDC |
DRD |
TC | SE2 |
DRD | RC | RJ | TID | IOS | SDC | SE2 | WR |
This ExecutablePath parameter may instead contain a reference to an ApplicationConstant from the currently active Application Map. The value of the retrieved constant will be used as the ExecutablePath.
For IOS: This should resolve to the full path to the Instruments trace template that will be used to launch the application.
For IOS: This should resolve to be the path to the directory that will contain the Instruments output log.
For RRAFS: Try to include all command line parameters within the ExecutablePath
If you DO provide separate command line paratmeters then the RRAFS DDE
cannot automatically terminate the application if things go really bad.
For IOS Device testing: the device and application must be specified exactly as they will appear in the Instruments "Choose Target" configuration menus. The parameters should be specified inline as:
Example: "-d Carls iPad (v5.0) -app UICatalog"
For IOS Simulator testing: this parameter is not needed and should not contain any -d or -app options.
For compatibility with different inputrecord separators, the SAFS/IOS engine supports different delimiters to be used with -d and -app. Supported Delimiters are (:;, ).
Examples:
(Of course, you cannot use a comma delimiter here if the inputrecord itself is comma delimited.)
TID | SDC |
RC | RJ | TID | SDC | WR | SE2 |
RC | RJ | TID | SDC | DRD | SE2 |
SE2 |
RJ | TC | SE2 |
TID | SE2 |
RC | TID | WR | SE2 |
RC | RJ | TID | SDC |
RJ | TID | SDC | DRD | SE2 |
RC | RJ | WR | SE | TC |
RC | RJ | TID | SDC |
RC | RJ | WR | SE | TC | AUT |
This only works on Windows or Components that have a valid Windows HANDLE (HWND) and can legally receive the focus at the time of the call.
TID | SE2 |
TID | SE2 |
TID |
TID | SE2 |
RJ | TID | SDC |
RC | RJ | TID | SDC |
RJ |
RJ |
RJ |
RJ |
RJ |
RC | RJ | TID | SDC |
RC | RJ | TID | SDC | SE2 |
RC | RJ | TID | SDC | WR | SE2 |
DRD |
RC | RJ | TID | SDC | WR | SE | SE2 |
Some browsers, like Internet Explorer, support other URLs like "about:home"-- which will launch the browser and display whatever the Home page is set to. However, not all browsers support this.
For consistency, it is usually necessary to include the full URL syntax--including the protocol portion of the URL (http://, https://, ftp://, etc..).
SE2 |
SE2 |
DRD | TID | SE2 |
TID |
TID |
TID |
TID |
RC | TID |
RC | TID |
RC | TID |
TID |
SE2 |
RJ | TID | SDC | DRD | SE2 |
SE2 |
SE2 |
RC | TID | WR |
DRD | RC | RJ | TID | WR | SE | SE2 | TC | AUT |
DRD | RC | RJ | TID | WR | TC | SE2 | AUT |
RC | RJ | WR | TC |
RC | RJ | WR | TC |
RJ | SDC | TID | SE2 |
RJ | SDC | TID | SE2 |
RC | RJ | WR | SE |
RC | TID | WR |
RC | TID | WR | SE2 |
RC | TID | WR |
RC | TID | WR | SE2 |
RC | TID | WR |
RC | TID | WR | SE2 |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR | SE2 |
RC | TID | WR | SE2 |
RC | TID | WR | SE2 |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR | SE2 |
RC | TID | WR | SE2 |
Consult ApplicationUtilities and Using DDVariables for more information on referencing these DDVariables in your tests.
You must adhere to DDVariable naming conventions when providing this DDVariable basename. Note that no spaces are allowed in DDVariable names.RC | TID | WR | SE2 |
RJ | TID | SDC |
RJ | TID | SDC |
OPTIONAL parameter. If specified the output file will contain only the number of columns specified. This number will become the first dimension of the retreival array. If NOT specified then no maximum.
OPTIONAL parameter. If specified the output file will contain only the number of columns specified. This number will become the first dimension of the retreival array. If NOT specified then no maximum.
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RC | RJ | TID | SDC | WR |
RC | RJ | TID | SDC | WR |
RC | RJ | TID | SDC | WR |
RC | RJ | TID | SDC | WR |
RC | RJ | TID | SDC | SE2 |
RC | RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
FilterMode | Comments |
WILDCARD | Default. Includes support for * and ? wildcard characters |
REGEXP | Includes support for Regular Expression pattern matching |
RC | RJ | TID | SDC | SE2 |
RC | RJ | TID | SDC | SE2 |
RC | RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
RC | RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
Note: Java-based engines like RFT should support using either a comma (,) or a semi-colon (;) as the Coords item separator. Also, there should be a space char separating each set of rectangle coordinates.
RC | RJ | TID | SDC | SE2 |
FILTERMODE | FIELDS | COMMENTS |
Default(empty) | (None) | Default filtering. File is unchanged. |
"RegExp" | 5 - PATTERN (Required) | REGEXP pattern to match for filtering. All occurrences of text in a file that match regular expression PATTERN will be removed and replaced with the REPLACE string (if any). |
6 - REPLACE (Optional) | Default value for REPLACE is "" (empty string). This tells REGEXP to remove matching PATTERN text from the file. Specifying a REPLACE string will remove matching PATTERN text from the file and insert the REPLACE string in its place. | |
7 - CASE (Optional) | CASE specifies the case-sensitivity used when searching for matching
text in the file. Use "CaseInsensitive" to ignore case when searching. If not specified the default implementation is a CaseSensitive compare. |
RC | TID | SDC |
RC | RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
RC | RJ | TID | SDC | SE2 |
Search directory using following file attributes. Default value is 0 - normal file.
0 - Normal file, returns only files without other attributes set
1 - Read Only file
2 - Hidden file
4 - System file (Window OS Only)
8 - Volume Label (Exclusive, if set, no other attribute counts.)
16 - Directory
32 - Archive file (Windows OS: attrib with 'A'; Other OS: file suffix is .jar, .tar, .rar, .gz etc.)
The values in the table can be added together to select multiple attributes.
For example, to list hidden and system files in addition to normal files set FileAttributes to 6 (6=2+4).
If FileAttributes is set to 8 (Volume Label), then returns the volume label of the drive specified in the pathname$, or of the current drive if drive is not explicitly specified.
If volume label attribute is set, all other attributes are ignored.
RC | RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
RJ | SDC | TID | SE2 |
The extension of the image file can be .bmp, .jpg, .gif, .tif, .png or .pnm.
Note: Seems TOCR performs a bit better than GOCR (personal experience).
LangId Language "en" --- English "cn" --- Chinese
If LangId is not specified with blank or empty string, the language of System locale will be used as default.
RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
RC | RJ | TID | SDC | SE2 |
Append Mode generally rewrites existing file contents with a NEWLINE between textual lines--stripping out OS-specific newline characters and making the file the same regardless of the platform.
AppendRaw Mode rewrites existing file contents without modification before appending any new data to the file.
RJ | TID | SDC | SE2 |
Append Mode generally rewrites existing file contents with a NEWLINE between textual lines--stripping out OS-specific newline characters and making the file the same regardless of the platform.
AppendRaw Mode rewrites existing file contents without modification before appending any new data to the file.
RC | RJ | TID | SDC | SE2 |
RC | RJ | TID | SDC | SE2 |
RC | RJ | TID | SDC | SE2 |
RC |
RC | RJ | TID | SDC | SE2 |
RJ | SDC | TID | SE2 |
The extension of the image file can be .bmp, .jpg, .gif, .tif, .png or .pnm.
Note: Seems TOCR performs a bit better than GOCR (personal experience).
LangId Language "en" --- English "cn" --- Chinese
If LangId is not specified with blank or empty string, the language of System locale will be used as default.
RC | RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
RC | TID | WR |
TID |
The Classes to execute must be findable within the JVM ClassPath.
SE2 | RC | IOS | RJ | WR |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
RC | WR | TID |
RC | WR | TID |
RC | TID | WR |
RC | RJ |
RC | WR | TID |
RC | WR | TID |
RC | TID | WR |
DRD | IOS | RC | RJ | TID | WR | SE | SE2 | TC |
DRD | IOS | RC | RJ | TID | WR | SE | SE2 | TC |
RC | TID | WR |
RC | TID | WR |
RC | RJ |
TID | RC |
RC | TID | WR |
TID |
RC | TID | WR |
TID |
RC |
TID | SDC |
TID | SDC |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
RC | TID | WR |
TID |
RC | WR | TID |
RC | WR | TID | SE2 |
RC | WR | TID | SE2 |
RC | WR | TID | SE2 |
RC | WR | TID | SE2 |
RC | WR | TID |
RC | TID | SE2 |
RC | TID | SE2 |
TID |
TID |
The Response/Request can stored be in more than one type of persistence storage;
For example, it can be in a XML file, a JSON file and "a series of variables" at the same time.
This keyword will delete all of them.
Please refer to keyword RestStoreResponse if you want to know exactly what type
of persistence storage can be used to save a REST response/request.
TID |
TID |
TID |
If this parameter means a 'variable prefix'.
The variablePrefix is used to deduce variables to store a REST response.
Deduced variables are listed as below:
If this parameter means a file name, then the information of a REST Response
(and Request if the parameter storeRequest is true) will be stored in a file.
The file could be a property file, a json file, or an XML file, examples as below:
Please pay attention to the special characters (new-line, double-quote, <?XML etc.)
escaped by the escape character shown in read as below.
a JSON file example { "Response":{ "StatusCode": "200", "Headers" : "{Date=Tue, 13 Dec 2016 03:32:13 GMT, Content-Length=4574, Content-Type=application/xml}", "EntityBody" : "<?xml version=\"1.0\"?><CUSTOMERList xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n <CUSTOMER xlink:href=\"http://www.thomas-bayer.com/sqlrest/CUSTOMER/0/\">0</CUSTOMER> \n</CUSTOMERList>", "Request": { "Method": "GET", "Headers": "{Date=Tue, 06 Dec 2016 03:08:12 GMT, Content-Length=4574}" } } } an XML file example: <Response> <StatusCode>200</StatusCode> <Headers>{Date=Tue, 13 Dec 2016 03:29:27 GMT, Content-Length=4574, Connection=keep-alive, Content-Type=application/xml}</Headers> <EntityBody><![CDATA[<?xml version="1.0"?><CUSTOMERList xmlns:xlink="http://www.w3.org/1999/xlink"> <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/0/">0</CUSTOMER> <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/49/">49</CUSTOMER> </CUSTOMERList>]]></EntityBody> <Request> <Method>GET</Method> <Headers> Content-Type:application/octet-stream, Accept:application/octet-stream </Headers> </Request> </Response> a Properties file example: Response.ContentType : application/xml Response.EntityBody : <?xml version="1.0"?><CUSTOMERList xmlns:xlink="http://www.w3.org/1999/xlink">\
\n <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/0/">0</CUSTOMER>\
\n <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/1/">1</CUSTOMER>\
\n </CUSTOMERList> Response.EntityLength : 0 Response.Headers : {Date=Mon, 12 Dec 2016 05:17:19 GMT, Content-Length=4762, Via=1.1 inetgw38 (squid), Connection=keep-alive, Content-Type=application/xml, X-Cache=MISS from inetgw38, Server=Apache-Coyote/1.1} Response.Request.Headers : Content-Type:application/octet-stream Accept:application/octet-stream
TID |
a JSON file example { "Response":{ "StatusCode": "200", "Headers" : "{Date=Tue, 13 Dec 2016 03:32:13 GMT, Content-Length=4574, Content-Type=application/xml}", "EntityBody" : "<?xml version=\"1.0\"?><CUSTOMERList xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n <CUSTOMER xlink:href=\"http://www.thomas-bayer.com/sqlrest/CUSTOMER/0/\">0</CUSTOMER> \n</CUSTOMERList>", "Request": { "Method": "GET", "Headers": "{Date=Tue, 06 Dec 2016 03:08:12 GMT, Content-Length=4574}" } } } an XML file example: <Response> <StatusCode>200</StatusCode> <Headers>{Date=Tue, 13 Dec 2016 03:29:27 GMT, Content-Length=4574, Connection=keep-alive, Content-Type=application/xml}</Headers> <EntityBody><![CDATA[<?xml version="1.0"?><CUSTOMERList xmlns:xlink="http://www.w3.org/1999/xlink"> <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/0/">0</CUSTOMER> <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/49/">49</CUSTOMER> </CUSTOMERList>]]></EntityBody> <Request> <Method>GET</Method> <Headers> Content-Type:application/octet-stream, Accept:application/octet-stream </Headers> </Request> </Response> a Properties file example: Response.ContentType : application/xml Response.EntityBody : <?xml version="1.0"?><CUSTOMERList xmlns:xlink="http://www.w3.org/1999/xlink">\
\n <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/0/">0</CUSTOMER>\
\n <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/1/">1</CUSTOMER>\
\n </CUSTOMERList> Response.EntityLength : 0 Response.Headers : {Date=Mon, 12 Dec 2016 05:17:19 GMT, Content-Length=4762, Via=1.1 inetgw38 (squid), Connection=keep-alive, Content-Type=application/xml, X-Cache=MISS from inetgw38, Server=Apache-Coyote/1.1} Response.Request.Headers : Content-Type:application/octet-stream Accept:application/octet-stream
TID |
a JSON file example { "Response":{ "StatusCode": "200", "Headers" : "{Date=Tue, 13 Dec 2016 03:32:13 GMT, Content-Length=4574, Content-Type=application/xml}", "EntityBody" : "<?xml version=\"1.0\"?><CUSTOMERList xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n <CUSTOMER xlink:href=\"http://www.thomas-bayer.com/sqlrest/CUSTOMER/0/\">0</CUSTOMER> \n</CUSTOMERList>", "Request": { "Method": "GET", "Headers": "{Date=Tue, 06 Dec 2016 03:08:12 GMT, Content-Length=4574}" } } } an XML file example: <Response> <StatusCode>200</StatusCode> <Headers>{Date=Tue, 13 Dec 2016 03:29:27 GMT, Content-Length=4574, Connection=keep-alive, Content-Type=application/xml}</Headers> <EntityBody><![CDATA[<?xml version="1.0"?><CUSTOMERList xmlns:xlink="http://www.w3.org/1999/xlink"> <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/0/">0</CUSTOMER> <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/49/">49</CUSTOMER> </CUSTOMERList>]]></EntityBody> <Request> <Method>GET</Method> <Headers> Content-Type:application/octet-stream, Accept:application/octet-stream </Headers> </Request> </Response> a Properties file example: Response.ContentType : application/xml Response.EntityBody : <?xml version="1.0"?><CUSTOMERList xmlns:xlink="http://www.w3.org/1999/xlink">\
\n <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/0/">0</CUSTOMER>\
\n <CUSTOMER xlink:href="http://www.thomas-bayer.com/sqlrest/CUSTOMER/1/">1</CUSTOMER>\
\n </CUSTOMERList> Response.EntityLength : 0 Response.Headers : {Date=Mon, 12 Dec 2016 05:17:19 GMT, Content-Length=4762, Via=1.1 inetgw38 (squid), Connection=keep-alive, Content-Type=application/xml, X-Cache=MISS from inetgw38, Server=Apache-Coyote/1.1} Response.Request.Headers : Content-Type:application/octet-stream Accept:application/octet-stream
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | SE2 |
RJ | TID | SDC | RC | SE2 |
RC | RJ | TID | SDC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
Name of DDVariable that will receive the result.
RJ | TID | SDC | RC | SE2 |
Name of DDVariable to receive the result
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
RJ | TID | SDC | SE2 |
RJ | RC | TID | SDC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC | RC | SE2 |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RJ | TID | SDC |
RC | WR |
RC | WR |
RC | WR |
RC | WR |
RC | WR |
RC | RJ | WR | SE | SE2 | TC | DRD |
WR |
RC | RJ | WR | SE | SE2 | TC | DRD |
RJ | DRD | TC | SE2 |
WR | TC |
RJ | SE2 |
RC | RJ | WR | SE | TC | DRD | SE2 |
RC | RJ | WR | SE | TC | DRD | SE2 |
RC | RJ | WR | SE | TC | DRD | SE2 |
RC | RJ | WR | SE | TC | DRD | SE2 |
SE2 |
RC | RJ | WR | TC | SE2 |
RC | RJ | TC |
RJ | SE2 |
RJ | TC | DRD | SE2 |
WR | TC |
RC | WR | TC |
RC | WR | TC |
RC | WR | TC |
RC | WR | TC |
RC | TC |
RC | WR | TC |
RC | WR | TC |
RC | RJ |
RC | RJ |
OPTIONAL parameter. If specified the output file will contain only the number of columns specified. This number will become the first dimension of the retreival array. If NOT specified the function will copy a maximum of 100 columns. (arbitrary limit for now)
OPTIONAL parameter. If specified the output file will contain only the number of columns specified. This number will become the first dimension of the retreival array. If NOT specified the function will copy a maximum of 100 columns. (arbitrary limit for now)
RC | RJ |
RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
DRD |
DRD |
RJ |
In RRAFS, this command will work on both JavaMenu items and JavaPopupMenu items.
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
The field header comparisons are not case-senstive, and provided values can be substrings of the actual header value in the table.
The field header comparisons are not case-senstive, and provided values can be substrings of the actual header value in the table.
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
These comparisons are not case-sensitive and can be substrings of the actual table text.
These comparisons are not case-sensitive and can be substrings of the actual table text.
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
DRD | RC | RJ | WR | TC | SE | SE2 |
RC | RJ | WR | TC | SE | SE2 | DRD | AUT |
DRD | RC | RJ | WR | TC | SE | SE2 |
RC | RJ | WR | TC | SE | SE2 | DRD |
RJ |
RJ |
RJ |
RJ |
RC |
RC |
RC |
RC |
RC |
RC |
RC |
RC |
RC | IOS | RJ | WR | SE | SE2 | TC |
RC | TC | RJ | SE | SE2 |
RJ | IOS | SE | SE2 | TC | DRD |
This parameter was added to this command in Nov 2011 as implemented for the Apple IOS engine and may not yet be supported in all engines otherwise supporting this command.
RJ | IOS | SE | SE2 | TC |
RJ | SE2 |
SE2 |
SE2 |
SE2 |
DRD | RC | RJ | IOS | TID | SE | SE2 | TC | AUT |
RJ | TID | SE | SE2 |
If this parameter is omitted with blank or empty string, full image of the component is captured (equivalent to "0,0,100%,100%").
Note: Seems TOCR performs a bit better than GOCR (personal experience).
LangId Language "en" --- English "cn" --- Chinese
If LangId is not specified with blank or empty string, the language of System locale will be used as default.
DRD | IOS | RC | RJ | TID | WR | SE | SE2 | TC |
DRD | IOS | RC | RJ | TID | WR | SE | SE2 | TC |
RC | TID | RJ | TC | SE | SE2 | AUT |
Name of the AppMap subkey to lookup and use for the hover. We expect the AppMap to contain the item in the format "x,y":
[Component]
Node1="33,120" OR
Node1="Coords=33,120" OR
Node1="Icon" (or whatever is appropriate)
The results from the lookup are appended to the "Coords=" string used by the hover command in Robot (if necessary). So any valid content used with the hover 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.
TID |
Name of the AppMap subkey to lookup and use for the hover. We expect the AppMap to contain the coordinates in the following supported formats:
[Component] Node1="33,120" (comma-delimited) OR Node1="33;120" (semi-colon delimited) OR Node1="33 120" (space-delimited) OR Node1="Coords=33,120" (comma-delimited) OR Node1="Coords=33;120" (semi-colon delimited) OR Node1="Coords=33 120" (space-delimited)
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.
This field can instead contain the literal text of any absolute or relative coordinates in the same formats as shown above.
RC | DRD | IOS | RJ | TID | WR | ABT | SE | SE2 |
RC | RJ | TID | WR | ABT | SE | SE2 | TC | DRD |
Note: the TID supports this command using InputKeys Support.
RJ | TC | SE | SE2 |
RJ | TID | TC | SE | SE2 |
RJ | TID | SE | SE2 |
If this parameter is omitted with blank or empty string, full image of the component is captured (equivalent to "0,0,100%,100%").
Note: Seems TOCR performs a bit better than GOCR (personal experience).
LangId Language "en" --- English "cn" --- Chinese
If LangId is not specified with blank or empty string, the language of System locale will be used as default.
RJ | TC |
If the event accepts multiple parameters, then each parameter must be provided in a separate field in the test record. All fields will be evaluated until no more fields are found to exist. All fields will be sent in the order they are provided.
RC | RJ | TC |
SE2 |
TID | DRD | SE2 |
TID |
This file should be kept VERY SECRECT, only the authorized users can access it.
TID | DRD | SE2 |
RC | RJ | WR |
RC | RJ | TID | TC |
RC | RJ | WR | TC |
RC | WR |
SE2 |
RC | RJ | TID | TC |
RC | RJ | IOS | TID | SE | SE2 | TC |
RC | RJ | SE | SE2 |
SE | SE2 |
IOS | DRD | SE | SE2 |
RC | RJ | IOS | WR | SE | SE2 | TC |
RC | RJ | IOS | WR | SE | SE2 | TC |
RC | IOS | RJ | WR | TC | SE | SE2 |
RC | WR |
The file is simply a list of component names in the order we expect to find them as we tab through the interface. Each line in the file will contain a single component name.
This file would normally be placed in the Datapool\Bench directory.
RC | RJ | TID | TC |
RC | RJ | TID | WR | TC |
TC | TID |
TID |
RC | RJ | TID | WR | TC |
RC | RJ | TID | WR | TC |
TID |
RJ | TC | SE2 |
Name of the AppMap subkey to lookup and use for an ALT left mouse drag. We expect the AppMap or literal text to contain the item in the format "x1,y1,x2,y2":
[GenericItem] DragName="3,10,12,20" OR DragName="Coords=3,10,12,20"
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.
DRD | RC | RJ | IOS | TID | WR | TC | ABT | SE | SE2 | AUT |
Name of the AppMap subkey to lookup and use for the click. We expect the AppMap or literal text to contain the item in the format "x,y":
[FolderTree] Node1="33,120" OR Node1="Coords=33,120" ... [AnHTMLImage] AMappdedRegion=Coords=10,10 ANamedRegion=AreaName=TechSupport AnIndexedRegion=AreaIndex=2 AnotherRegion=AreaID=Contact
The results from the lookup are appended to the "Coords=" string used by the Click command in Robot (only if necessary). So any valid content used with the 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.
The Rational Robot implementation also supports using literal text in this parameter instead of an AppMapSubKey. If the value retrieved from this field is NOT found to exist in the App Map as a Sub Key then it will be used as literal text as if it HAD been retrieved from the App Map.
Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:
Important TID note. The TID IBT implementation supports using literal text in this parameter instead of an AppMapSubKey. If the value retrieved from this field is NOT found to exist in the App Map as a Sub Key then it will be used as literal text as if it HAD been retrieved from the App Map.
Any coordinates provided for TID IBT are considered relative to the top-left (0,0) of the image or item found unless PointRelative and\or Hotspot information in the IBT recognition string change this initial relative point to be somewhere else.
Important Abbot note. Presently, there is no support for AppMapSubkey specification (5th field).
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.
TID |
TID |
Name of the AppMap subkey to locate in the App Map. We expect the AppMap to contain the coordinates in the following supported formats:
[Component] Node1="33,120" (comma-delimited) OR Node1="33;120" (semi-colon delimited) OR Node1="33 120" (space-delimited) OR Node1="Coords=33,120" (comma-delimited) OR Node1="Coords=33;120" (semi-colon delimited) OR Node1="Coords=33 120" (space-delimited)
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.
This field can instead contain the literal text of any absolute or relative coordinates in the same formats as shown above.
TID |
"33,120" (comma-delimited) OR "33;120" (semi-colon delimited) OR "33 120" (space-delimited)
Note the "Coords=" prefix is NOT supported for this deprecated command.
RC |
RC | WR |
RJ | TC | SE2 |
Name of the AppMap subkey to lookup and use for the CTRL ALT left mouse drag. We expect the AppMap or literal text to contain the item in the format "x1,y1,x2,y2":
[GenericItem] DragName="3,10,12,20" OR DragName="Coords=3,10,12,20"
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 | TID | TC | ABT | SE | SE2 | AUT |
Name of the AppMap subkey to lookup and use for the CTRL-click. We expect the AppMap to contain the item in the format "x,y":
[ToolItem] PrintTool="33,120" OR PrintTool="Coords=33,120"
The results from the lookup are appended to the "Coords=" string used by the GenericObject Ctrl_Click command in Robot (if necessary). So any valid content used with the Ctrl_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.
Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:
Important Abbot note. Presently, there is no support for AppMapSubkey specification (5th field).
TID |
RJ | TC | SE2 |
Name of the AppMap subkey to lookup and use for the CTRL left drag. We expect the AppMap or literal text to contain the item in the format "x1,y1,x2,y2":
[GenericItem] DragName="3,10,12,20" OR DragName="Coords=3,10,12,20"
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 | TID | RJ | SE | SE2 |
Name of the AppMap subkey to lookup and use for the CTRL-Right-Click. We expect the AppMap to contain the item in the format "x,y":
[ToolItem] PrintTool="33,120" OR PrintTool="Coords=33,120"
The results from the lookup are appended to the "Coords=" string used by the GenericObject CTRL-Right-Click command in Robot (if necessary). So any valid content used with the CTRL-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.
TID |
RJ | TC | SE2 |
Name of the AppMap subkey to lookup and use for the CTRL SHIFT left mouse drag. We expect the AppMap or literal text to contain the item in the format "x1,y1,x2,y2":
[GenericItem] DragName="3,10,12,20" OR DragName="Coords=3,10,12,20"
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 | IOS | TID | TC | WR | ABT | SE | SE2 | AUT |
Name of the AppMap subkey to lookup and use for the double click. We expect the AppMap or literal text to contain the item in the format "x,y":
[FolderTree] Node1="33,120" OR Node1="Coords=33,120"
The results from the lookup are appended to the "Coords=" string used by the GenericObject DBLClick command in Robot (if necessary). So any valid content used with the 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.
Important Abbot note. Presently, there is no support for AppMapSubkey specification (5th field).
Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:
Important TID note. The TID IBT implementation supports using literal text in this parameter instead of an AppMapSubKey. If the value retrieved from this field is NOT found to exist in the App Map as a Sub Key then it will be used as literal text as if it HAD been retrieved from the App Map.
Any coordinates provided for TID IBT are considered relative to the top-left (0,0) of the image or item found unless PointRelative and\or Hotspot information in the IBT recognition string change this initial relative point to be somewhere else.
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.
TID |
TID |
Name of the AppMap subkey to locate in the App Map. We expect the AppMap to contain the coordinates in the following supported formats:
[Component] Node1="33,120" (comma-delimited) OR Node1="33;120" (semi-colon delimited) OR Node1="33 120" (space-delimited) OR Node1="Coords=33,120" (comma-delimited) OR Node1="Coords=33;120" (semi-colon delimited) OR Node1="Coords=33 120" (space-delimited)
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.
This field can instead contain the literal text of any absolute or relative coordinates in the same formats as shown above.
TID |
"33,120" (comma-delimited) OR "33;120" (semi-colon delimited) OR "33 120" (space-delimited)
Note the "Coords=" prefix is NOT supported for this deprecated command.
IOS |
TC | SE2 |
IOS |
Name of the AppMap subkey to lookup and use for the command. We expect the AppMap or literal text to contain the item in the format "x1,y1,x2,y2":
[ComponentName] OffsetName="0;0;100;100"
Both Fields #3 (Component Name) and #5 (Offset Name) 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.
If no such App Map lookup exists, then we will assume the field contains the offset value directly.
Offsets are "relative" to the object. Each value should be an integer 0-100 representing the relative percentage where 0 is the minimum (left or top) and 100 is the maximum width or height of the object. Thus: 0,0,100,100 represents a flick from the topleft corner to the bottomright corner of the object.
Engines should attempt to support offsets separated by different characters. The most common separators that should be supported would be:
IOS |
IOS |
IOS |
IOS |
RC | RJ | TC |
RC | WR |
Name of the Java menuitem to lookup and use for the selection. We expect the AppMap to contain the item in the format "Path=Menu->Item":
[MainMenu] FileOpen="Path=File->Open"
The full results from the AppMap lookup are used, so any valid content used with the JavaMenu 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 | TID | TC | WR | SE2 |
Name of the AppMap subkey to lookup and use for the left drag. We expect the AppMap or literal text to contain the item in the format "x1,y1,x2,y2":
[GenericItem] DragName="3,10,12,20" OR DragName="Coords=3,10,12,20"
The results from the lookup are appended to the "Coords=" string used by the GenericObject Left_Drag command in Robot (if necessary). So any valid content used with the Left_Drag 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.
Important TID note. The TID IBT implementation supports using literal text in this parameter instead of an AppMapSubKey. If the value retrieved from this field is NOT found to exist in the App Map as a Sub Key then it will be used as literal text as if it HAD been retrieved from the App Map.
Any coordinates provided for TID IBT are considered relative to the top-left (0,0) of the image or item found unless PointRelative and\or Hotspot information in the IBT recognition string change this initial relative point to be somewhere else.
RJ |
Name of the AppMap subkey to lookup and use for the click. We expect the AppMap or literal text to contain the item in the format "x,y":
[FolderTree] Node1="33,120" OR Node1="Coords=33,120" ... [AnHTMLImage] AMappdedRegion=Coords=10,10 ANamedRegion=AreaName=TechSupport AnIndexedRegion=AreaIndex=2 AnotherRegion=AreaID=Contact
The results from the lookup are appended to the "Coords=" string used by the MouseClick command in Robot (only if necessary). So any valid content used with the MouseClick 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.
The Rational Robot implementation also supports using literal text in this parameter instead of an AppMapSubKey. If the value retrieved from this field is NOT found to exist in the App Map as a Sub Key then it will be used as literal text as if it HAD been retrieved from the App Map.
Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:
TID |
Name of the AppMap subkey to lookup and use for the click. We expect the AppMap or literal text to contain the item in the format "x,y":
[FolderTree] Node1="33,120" OR Node1="Coords=33,120" ... [AnHTMLImage] AMappdedRegion=Coords=10,10 ANamedRegion=AreaName=TechSupport AnIndexedRegion=AreaIndex=2 AnotherRegion=AreaID=Contact
The results from the lookup are appended to the "Coords=" string used by the Click command in Robot (only if necessary). So any valid content used with the 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.
Important TID note. The TID IBT implementation supports using literal text in this parameter instead of an AppMapSubKey. If the value retrieved from this field is NOT found to exist in the App Map as a Sub Key then it will be used as literal text as if it HAD been retrieved from the App Map.
Any coordinates provided for TID IBT are considered relative to the top-left (0,0) of the image or item found unless PointRelative and\or Hotspot information in the IBT recognition string change this initial relative point to be somewhere else.
TID |
Note: the TID supports this command using Image-Based Testing techniques and App Map entries as well as literal text coordinates.
DRD | IOS |
RC | RJ | TID | TC | WR | ABT | SE | SE2 | AUT |
Name of the AppMap subkey to lookup and use for the right click. We expect the AppMap or literal text to contain the item in the format "x,y":
[ToolItem] PrintTool="33,120" OR PrintTool="Coords=33,120"
The results from the lookup are appended to the "Coords=" string used by the GenericObject Right_Click command in Robot (if necessary). So any valid content used with the 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.
Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:
Important TID note. The TID IBT implementation supports using literal text in this parameter instead of an AppMapSubKey. If the value retrieved from this field is NOT found to exist in the App Map as a Sub Key then it will be used as literal text as if it HAD been retrieved from the App Map.
Any coordinates provided for TID IBT are considered relative to the top-left (0,0) of the image or item found unless PointRelative and\or Hotspot information in the IBT recognition string change this initial relative point to be somewhere else.
Important Abbot note. Presently, there is no support for AppMapSubkey specification (5th field).
TID |
TID |
Name of the AppMap subkey to locate in the App Map. We expect the AppMap to contain the coordinates in the following supported formats:
[Component] Node1="33,120" (comma-delimited) OR Node1="33;120" (semi-colon delimited) OR Node1="33 120" (space-delimited) OR Node1="Coords=33,120" (comma-delimited) OR Node1="Coords=33;120" (semi-colon delimited) OR Node1="Coords=33 120" (space-delimited)
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.
This field can instead contain the literal text of any absolute or relative coordinates in the same formats as shown above.
TID |
"33,120" (comma-delimited) OR "33;120" (semi-colon delimited) OR "33 120" (space-delimited)
Note the "Coords=" prefix is NOT supported for this deprecated command.
RC | RJ | TID | WR | TC | SE2 |
Name of the AppMap subkey to lookup and use for the right drag. We expect the AppMap or literal text to contain the item in the format "x1,y1,x2,y2":
[GenericItem] DragName="3,10,12,20" OR DragName="Coords=3,10,12,20"
The results from the lookup are appended to the "Coords=" string used by the GenericObject Left_Drag command in Robot (if necessary). So any valid content used with the Right_Drag 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.
Important TID note. The TID IBT implementation supports using literal text in this parameter instead of an AppMapSubKey. If the value retrieved from this field is NOT found to exist in the App Map as a Sub Key then it will be used as literal text as if it HAD been retrieved from the App Map.
Any coordinates provided for TID IBT are considered relative to the top-left (0,0) of the image or item found unless PointRelative and\or Hotspot information in the IBT recognition string change this initial relative point to be somewhere else.
RC | RJ | TID | TC | WR | ABT | SE | SE2 | AUT |
Name of the AppMap subkey to lookup and use for the SHIFT click. We expect the AppMap to contain the item in the format "x,y":
[ToolItem]
PrintTool="33,120" OR PrintTool="Coords=33,120"
The results from the lookup are appended to the "Coords=" string used by the GenericObject Shift_Click command in Robot (if necessary). So any valid content used with the Shift_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.
Engines should also attempt to support coordinates separated by alternate separators. The most common separators that should be supported would be:
Important Abbot note. Presently, there is no support for AppMapSubkey specification (5th field).
TID |
RJ | TC | SE2 |
Name of the AppMap subkey to lookup and use for the operation. We expect the AppMap or literal text to contain the item in the format "x1,y1,x2,y2":
[GenericItem] DragName="3,10,12,20" OR DragName="Coords=3,10,12,20"
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.
DRD | IOS |
IOS |
RC |
RC | RJ | TC |
WR |
RC | WR |
RC | RJ | SE |
RC | RJ | SE |
RC | RJ | SE |
RC | RJ | SE |
RC | RJ | SE |
RC | SE |
RC | RJ | SE |
RC | RJ | SE |
WR |
(OPTIONAL) Name of the AppMap subkey to lookup and use for the click. The AppMap can contain the item in any of the following formats:
[AnImage] AMappdedRegion=Coords=10,10 ANamedRegion=AreaName=TechSupport AnIndexedRegion=AreaIndex=2 AnotherRegion=AreaID=Contact
Any valid content used with the HTMLImage 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.
RJ |
The AppMap could contain the item in any of the following formats:
[AnImage] AMappdedRegion=Coords=10,10 ANamedRegion=AreaName=TechSupport AnIndexedRegion=AreaIndex=2 AnotherRegion=AreaID=Contact
Both Fields #3 and #5 would be used to locate the item in the App Map. This routine does not specify an App Map so only the current Map would be used and it is expected to be valid.
WR |
WR |
RC | RJ |
(Required) Name of the file to use for the image save-as command. This can be a full or relative path or a simple filename. A relative path will be stored relative to the Project's root directory. If a simple filename is provided it will be stored in the Project's Datapool\Test directory.
We expect the coordinates in the format "x,y":
[MyImage] TopRight=50,10 Center=25,25 BottomRight=Coords=50,40
The results from the lookup are appended to the "Coords=" string used by the Click command in Robot (if necessary).
Both Fields #3(component name) and #6(coords reference name) 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.
If this parameter is not provided, we will use default coordinates of 3,3 for the right click.
RC | RJ |
(REQUIRED) Name of the file to use for the image save-as command and the benchmark file. This can also be a full or relative path suitable for FindSQAFile. If no full path or relative path is given then the benchmark file is expected to be found in the project's Datapool\Bench directory.
The captured image will be stored in the project's Datapool\Test project's Datapool/Test directory. Any comparison difference will be stored in the project's Datapool\Dif directory.
We expect the coordinates in the format "x,y":
[MyImage] TopLeft=10,10 Center=Coords=25,25
The results from the lookup are appended to the "Coords=" string used by the Click command in Robot (if necessary).
Both Fields #3(component name) and #6(coords reference name) 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.
If this parameter is not provided, we will use default coordinates of 3,3 for the right click.
WR |
WR |
WR |
RJ | SE |
RJ | SE |
The field header comparisons are not case-senstive, and provided values can be substrings of the actual header value in the table.
The field header comparisons are not case-senstive, and provided values can be substrings of the actual header value in the table.
RJ | SE |
RJ | SE |
RJ | SE |
RJ | SE |
WR |
Name of the AppMap subkey to lookup and use for the click. The AppMap can contain the item in any of the following formats:
[ATable]
AMappedRegion=Coords=10,10
ANamedRegion=Coords=10,10,25,25
AnIndexedRegion=Col=1;Row=1
Any valid content used with the HTMLTable 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 |
WR |
WR |
RJ | SE |
RJ | SE |
RJ | SE |
RJ | SE |
These comparisons are not case-sensitive and can be substrings of the actual table text.
These comparisons are not case-sensitive and can be substrings of the actual table text.
RJ | SE |
RJ | SE |
RJ |
RJ | SE |
RJ | SE |
RJ | SE |
RJ | SE |
RJ | SE |
RJ | SE |
RJ | WR | SE |
RJ | SE |
RJ | SE |
RJ | SE |
RJ | SE |
TC |
RC | RJ | TC | SE2 |
RC | RJ | TC | SE2 |
RJ | TC | SE2 |
RJ | TC | SE2 |
RJ | TC | SE2 |
RC | RJ | TC |
RJ | TC |
RC | RJ | TC |
The field header comparisons are not case-senstive, and provided values can be substrings of the actual header value in the table.
The field header comparisons are not case-senstive, and provided values can be substrings of the actual header value in the table.
RC | RJ | TC |
RC | RJ | TC |
RC | RJ | TC |
RC | RJ | TC |
RC | RJ | TC |
RC | RJ | TC |
RJ | TC |
RC | RJ | TC |
RJ | TC |
RC | RJ | TC |
RJ | TC |
RC | RJ | TC |
RC | RJ | TC |
These comparisons are not case-sensitive and can be substrings of the actual table text.
These comparisons are not case-sensitive and can be substrings of the actual table text.
RC | RJ | TC |
RC | RJ | TC |
RJ | TC |
RC | RJ | TC |
RC | RJ | TC |
RJ | TC |
RC | RJ | TC |
RC | RJ | TC |
RJ | TC |
RJ | TC |
RC | RJ | TC |
RC | RJ | TC |
RJ | TC |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ |
RJ |
RC | RJ |
RC | RJ |
WR |
RC | RJ | WR | SE |
RC | RJ | WR | SE |
RC | RJ | SE |
RC | RJ | SE |
No check is performed after the selection to verify success. This is typically done for cases when the listbox is only temporary in nature and disappears immediately upon a selection.
RJ |
RJ |
RJ |
RJ |
RJ |
RJ |
RC | RJ | SE |
RC | RJ | SE |
RJ | SE |
RC | RJ | WR | SE |
RC | RJ | WR | SE |
RC |
RC | RJ | SE |
RC | RJ | SE |
No check is performed after the selection to verify success. This is typically done for cases when the listbox is only temporary in nature and disappears immediately upon a selection.
RJ |
RJ |
RC | RJ | WR | SE |
RC | RJ | WR | SE |
RC | RJ | SE |
RC | RJ | WR | SE |
RC | RJ | SE |
RJ |
RJ |
RJ |
RC | RJ | WR | SE |
RC | RJ | WR | SE |
DRD | SE2 |
DRD | SE2 |
TC | DRD | SE2 |
The value of the parameter can have 2 forms:
RC | WR | TC | DRD | SE2 |
The value of the parameter can have 2 forms:
RC | SE2 |
We expect the coordinates in the format "x,y":
[MyListView]
Center=5,120 OR
Center=Coords=5,120
The results from the lookup are appended to the "Coords=" string used by the Click command in Robot (if necessary).
Both Fields #3(component name) and #6(coords reference name) 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.
The value of the parameter can have 2 forms:
RC | TC | DRD | SE2 |
The value of the parameter can have 2 forms:
RC | SE2 |
We expect the coordinates in the format "x,y":
[MyListView]
Center=5,120 OR
Center=Coords=5,120
The results from the lookup are appended to the "Coords=" string used by the Click command in Robot (if necessary).
Both Fields #3(component name) and #6(coords reference name) 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.
The value of the parameter can have 2 forms:
RC |
DRD | TC | SE2 |
DRD | SE2 |
DRD | SE2 |
TC | SE2 |
RC | TC | SE2 |
The value of the parameter can have 2 forms:
RC | SE2 |
We expect the coordinates in the format "x,y":
[MyListView]
Center=5,120 OR
Center=Coords=5,120
The results from the lookup are appended to the "Coords=" string used by the Click command in Robot (if necessary).
Both Fields #3(component name) and #6(coords reference name) 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.
The value of the parameter can have 2 forms:
RC |
The value of the parameter can have 2 forms:
RC |
We expect the coordinates in the format "x,y":
[MyListView]
Center=5,120 OR
Center=Coords=5,120
The value of the parameter can have 2 forms:
TC | SE2 |
The value of the parameter can have 2 forms:
TC | SE2 |
The value of the parameter can have 2 forms:
DRD | SE2 |
RC | WR | TC | DRD | SE2 |
RC | SE2 |
We expect the coordinates in the format "x,y":
[MyListView]
Center=5,120 OR
Center=Coords=5,120
TC | DRD | SE2 |
The value of the parameter can have 2 forms:
RC | WR |
RC | WR | TC | DRD | SE2 |
The value of the parameter can have 2 forms:
RC | SE2 |
We expect the coordinates in the format "x,y":
[MyListView]
Center=5,120 OR
Center=Coords=5,120
The results from the lookup are appended to the "Coords=" string used by the Click command in Robot (if necessary).
Both Fields #3(component name) and #6(coords reference name) 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.
The value of the parameter can have 2 forms:
RC | TC | DRD | SE2 |
The value of the parameter can have 2 forms:
RC | SE2 |
We expect the coordinates in the format "x,y":
[MyListView]
Center=5,120 OR
Center=Coords=5,120
The value of the parameter can have 2 forms:
RC | TC | SE2 |
RC | WR | TC | SE2 |
RC | TC | SE2 |
RC | WR | TC | SE2 |
RC |
RC | RJ | TC |
RC | RJ | TC |
RC | RJ |
RC |
"Enabled" "Grayed" "BarBreak" "Bitmap" "Disabled" "Ungrayed" "Separator" "Break" "Checked" "Hilited" "Default" "Menu With N MenuItems" "Unchecked" "Unhilited" "Normal" (not default)
RC | RJ |
For RC and Win32 popups: The Window and Component references are not used and can be anything. They just cannot be blank.
For Java popups: Valid recognition information for the Java window and "child" popup menu must be provided.
Also refer to JavaMenuFunctions for support specific to Java menus and popup menus.
Note: this parameter is partial supported for RJ.
Expected status string (or part thereof) to verify. Ex: "Enabled Checked" OR "Disabled Grayed" etc. Each item separated by a space will be evaluated separately so the order of the status items does not matter. These status items (listed below) currently ARE case-sensitive.
"Enabled" "Grayed" "BarBreak" "Bitmap" "Disabled" "Ungrayed" "Separator" "Break" "Checked" "Hilited" "Default" "Menu With N MenuItems" "Unchecked" "Unhilited" "Normal" (not default)
"Enabled" "Grayed" "Bitmap" "Disabled" "Ungrayed" "Separator" "Checked" "Unchecked" "Menu With N MenuItems" are supported by RJ.
RJ |
For Java popups: Valid recognition information for the Java window and "child" popup menu must be provided.
Also refer to JavaMenuFunctions for support specific to Java menus and popup menus.
DRD |
DRD |
DRD |
DRD |
WR | TC |
RC | WR | TC |
WR | TC |
RC | RJ | WR | TC | DRD | SE2 |
RC | RJ | WR | TC | DRD | SE2 |
RC | RJ | WR | TC | DRD | SE2 |
RC | RJ | WR | TC | DRD | SE2 |
RC | RJ | WR | TC | DRD | SE2 |
RC | RJ | WR | TC | DRD | SE2 |
RC | RJ | WR | TC | DRD | SE2 |
RC | RJ | WR | TC | DRD | SE2 |
RC | WR |
RC | WR |
RC | WR |
RC | WR |
RC | WR |
WR |
RC | RJ | WR | TC | DRD | SE2 |
RJ | TC | DRD | SE2 |
RC | RJ | WR | TC | DRD | SE2 |
RC | RJ | WR | TC | DRD | SE2 |
RC | RJ | TC | DRD | SE2 |
WR |
RC | RJ | TC | DRD | SE2 |
WR |
WR |
WR |
WR |
WR |
WR |
WR |
TID |
TID |
TID |
TID |
TID |
TID |
TID |
TID |
TID |
TID |
TID |
TID |
TID |
DRD |
DRD |
RC | TC |
RJ | TC |
RC | RJ | TC |
RJ |
RC |
RC | RJ | TC |
RC |
RC |
RC |
RC |
RC | RJ |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
RC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ |
RC | RJ | WR | TC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | SE2 |
RJ | SE2 |
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ |
RC | RJ | WR | TC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | SE2 |
RC | RJ |
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ |
RC | RJ |
RC | RJ |
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC |
TC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | WR | TC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
TC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | TC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
RC | RJ | SE2 |
RJ | SE2 |
RC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | WR | TC | SE2 |
RC | RJ | WR | TC | SE2 |
RC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC |
The value of the parameter can have 2 forms:
If the field parameter data does not match one of these two forms then the data is ignored and the default(first match) is used.
RC | RJ | TC | SE2 |
RC | RJ | TC | SE2 |
RC |
RC |
RC |
WR |
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 |
WR |
WR |
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 |
DRD |
WR |
WR |
RC | RJ | WR | SE | TC | SE2 | AUT |
RC | RJ | WR | SE | TC | SE2 | AUT |
IOS |
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 |
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 |
WR |
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 |
RC | RJ | WR |
SE |
RC | RJ | WR | SE | TC | SE2 | AUT |
RC | WR |
RC | WR |
RC | WR |
RC | RJ | WR |
RC | RJ | WR |
RC | WR |
|