Overview: Handling Special Case Screens

In a standard or expected navigation flow; a task consists of a series of screens with inputs, outputs, and transition actions, linked together as task steps, each step having an expected destination screen. A task will not recognize a screen when it does not match any of the expected screens in your NavMap, (even if the screen might appear in another location in the NavMap), and the task will fail.

These unexpected screens, commonly a message sent from the host or other type of host-initiated screen, can derail your task. Unexpected screens of this type are called global screens. Configuring global screen handlers to handle these screens provides robustness to your tasks. Global screen handlers also provide the Runtime Service with a tool to use to get the task navigation back on track and to avoid navigation failures.

When confronted with a navigation error, the Runtime Service checks the list of global screen handlers you have created to see if any of the listed screens match the current screen. If there is a match, the run-time issues the appropriate transition action that was set up when you created the global screen handler.

Setting up Global Screen Handlers

When you record a task, you designate any message screens that commonly occur when running a task as global screens. Then, when the Runtime Service encounters one of the marked screens, you are prompted to choose whether to use the global screen handler to get the task back on track or continue recording.

Global screen handlers consist of a screen definition and a transition action. After dismissing a global screen, the Runtime Service expects to be on the next step in the task. If it is not, it checks the global screen handlers again for another alternative before failing the task.

Using global variables

You can use global variables to handle host screens, such as inactivity lockout screens, where a task input is required before the task can continue. By simply renaming your task input GLOBAL_xxxx, when you record and define the global screen handler that will dismiss the inactivity lockout, you can change the value/expression associated with the task input on that screen to GLOBAL_xxxx.

About Unformatted Screens

A screen that does not contain fields defined by the host application is an unformatted screen. When Task Builder encounters one of these screens during recording, in order to either extract data from the screen or enter data onto the screen, Task Builder creates an unprotected field that encompasses the entire screen.

Note NVT and SSCP-LU screens are considered unformatted screens and are handled accordingly. If you are using Synapta Services Builder for VT, for more information on the unformatted and automatically formatted screen options, see Automatically Adding User Fields to VT Screens.

Task Builder uses the cursor position on the screen to determine what data will be recorded as an input to a task or sent to the host. Data located between the original cursor position and the final cursor position following the text input on the screen is used.

The cursor is always placed at the "next” input position, thus when the host sends its output, the cursor will be located at the point where you begin to type. As you type, the cursor is always one position to the right of the last character typed.

Cursor Position on Unformatted Screens
Caution Because cursor placement on unformatted screens is handled automatically, use caution when setting a cursor row or cursor column position.

For detailed information on Cursor Row and Cursor Column properties, see Task and Task Step Property Descriptions.

Related Topics
Bullet Designing Tasks, Overview
Bullet Handling Global Screens
Bullet Using Global Variables
Bullet Automatically Adding User Fields to VT Screens
Bullet Task and Task Step Property Descriptions
  Attachmate