Screen transition handling refers to the way in which the changing beween active screens is handled. It is important to be able to determine if there has been a host screen update; and if the screen has changed, whether the active screen is the one expected. The main issues resulting from screen transitions that have to be dealt with are:
•Delays - this normally happens when there is host lag, or the current task being executed by the host is a time-consuming one.
•Error messages - unexpected screens that have to be dealt with in an appropriate manner.
•Message screens - some applications provide brief, timed, messages before returning to the expected screen. A choice has to be made whether to ignore these messages, or to record the information they provide.
From the above three issues it sometimes becomes unclear as to whether an issue is a transitional or navigational one. The differentiation between the two may actually be dependent upon the requirement of the transaction. For example, would it be necessary to capture the information from message screens or to ignore it and wait until the expected screen appears? Flynet Viewer provides the functionality to cope with these issues.
There are three ways of handling screen transitions with Flynet Viewer:
| 1. | Monitor for an update to text on the active screen. |
| 2. | Use the built-in HostScreen object methods to monitor for screen updates. |
| 3. | Use the built-in HostScreen object methods that use screen definitions to monitor for screen updates. |
The first method is only mentioned here because it is an option. It is just not a very good one and is not recommended. By writing a loop that continuously checks a specific part of the currently active screen for text, it is possible to determine when a screen has changed. It is not a very robust method and should be avoided.
The second method uses the built-in commands such as:
•waitForUpdate
•putWithWait
•waitForCursor
These distinguish themselves in that they are synchronous. Control is only returned to the caller once an update has occured or the specified timeout period has elapsed.
The third method is similar to the second, but it is more closely coupled with the host application. It requires that a definition file be created (refer to Screen Recognition). The definition file contains screen recognition information which is used by the HostScreen object. It enables the use of the following commands:
•getScreenName
•waitForScreen
The getScreenName method retrieves the name of the currently active screen. The waitForScreen method waits until either the specified screen becomes active, or until the specified amount of time has elapsed.
The waitForUpdate method is used when it is known that there is going to be a screen change and when either:
•Definition files are not being used, which means that there are no defined screen names.
or
•It is uncertain what the name of the next screen is going to be.
The waitForScreen method is used when there is a definition file. It particularly useful:
•In situations where the host application throws one or more message screens that only appear for a short period of time before returning to a menu. These message screens can be ignored, and control only returned once the expected menu screen appears. Alternatively the message screen can be the expected screen and the message captured.
•Where there is a part of the host application where it is known to have lag time - for example some hosts can be slow during the signon process.
In both these scenarios the waitForScreen will wait until either the expected screen appears, or the timeout period elapses.
The following sample code demonstrates some transition handling techniques.
The example has 6 functions/routines:
•connect
•disconnect
•navigateToAcctUpdate
•processUpdateScreen
•navigateToPolicySelect
•specialWait
The connect and disconnect are self-explanatory.
The navigateToAcctUpdate function demonstrates one style of handling navigation through a host system. Using the SELECT CASE statement (other languages call the statement SWITCH) it is possible to select the correct screen and process the navigation required for that screen. There are other methods of handling the navigation, each dependant upon the project requirements. For example:
•State control - Create a function for each screen. A system action state variable can be used to determine what action should be taken for that specific screen.
•Database control - A database can store navigation information. A generic set of functions can then be used to process the data from the database to handle host screen navigation.
The specialWait function demonstrates some very interesting and powerful features of the waitForScreen method. First, it uses the "*!" option instead of a specific screen name. This option means that it will wait until for any new screen that is not the default, and that is not the last screen recognised. The default screen is one that encompasses all screens that have not been defined in the definition file.
Another feature used in the waitForScreen method is the option to throw an error. The is done by using the "[error message]" syntax within the ScreenNames parameter of the method. An error is thrown when none of the screens in the ScreenNames parameter are recognised. In this case, a personalised message would be thrown with the message "Not on a different screen".
The processUpdateScreen function does not modify any of the data in the host screen, but it still sends the ENTER action command to update the current data. It then uses the waitForUpdate method to ensure that the host screen has been updated. It is known that there is a message screen after the update action is sent, and this message is captured and displayed.
Another important feature in this function is the handling of the message screen. It is only displayed for a short period before the next host scren is displayed. Once the message has been retrieved, it is important to wait until the message screen has disappeared so that control is only returned once the system is in a known and stable state.
The navigateToPolicySelect function uses the same technique as the navigateToUpdate function in order to navigate to a specific screen.
