Handling Multi-5250 Screen Data Entry
In this scenario three 5250 screens are used to input new orders like this:
We need to do is to make them all work on a single command handler tab like this, handling the "New" command for business object "Order":
Here's an outline of the steps required to do this and some ideas about how this common type of 5250 interaction might be modernized:
· First, enroll Screen A, Screen B and Screen C in RAMP as destinations.
· Now, link Screen A to the "New" command in the "Orders" business object.
· Do not link destination screens B or C to anything. They are defined as destinations only so that RAMP can control their function keys and execute scripts associated with them. They are never directly accessed by any command, so their INVOKE scripts will never be used.
· Now examine and think about the INVOKE, BUTTON and RETURN scripts associated with each of screen A, B and C as follows:
| Screen A | Screen B | Screen C |
INVOKE script | Should be okay as generated. | Should never be used, so delete any script lines or add an error message. | Should never be used, so delete any script lines or add an error message. |
BUTTON script | Successful Enter/OK button usage should cause Screen B to appear. | Successful Enter/OK button usage should cause Screen C to appear | After successful Enter/OK button you would probably script for, or, try using NAVIGATE_TO_DESTINATION("Screen A") to start another new order being input |
RETURN script | Should be okay as generated | Make sure it navigates back to the correct junction and not back to screen A. | Make sure it navigates back to the correct junction and not back to screen B. |
The preceding table mentions "Successful Enter/OK button usage". This means that your script does a SENDKEY(KeyEnter) and then possibly checks that everything went as expected.
As generated, default scripts probably would handle the Screen A -> B -> C flow automatically, but it might be useful to understand how this happens so that you can modify the behavior. Consider this modified partial BUTTON script:
/* The user has clicked the OK button or pressed the enter key on screen A */
case KeyEnter:
/* Send the enter key on Screen A to the System i 5250 server */
SENDKEY(KeyEnter);
/* Now handle the screen that results (ie: after sending the Enter key) */
switch ( CURRENT_FORM() )
{
/* If screen B is now being displayed we have advanced to the 2nd screen. */
/* There is nothing more to do as screen B's scripts will now take over. */
case "Screen B":
break;
/* If Screen A is still being displayed the user has probably made a data entry error */
case "Screen A":
ALERT_MESSAGE("Please correct the data entry errors and click OK again.");
break;
/* If we reach here, then some unexpected screen is being displayed */
default:
HIDE_MESSAGE("Unexpected screen " + CURRENT_FORM() + " encountered." );
break;
}
break;
· Finally, think about adding, re-labeling or changing buttons and function keys so as to get a more Windows like "Previous" -> "Next" -> "Save" flow going on between screens A, B and C. Possibly something like this:
| Has a "Next" Button | Has a "Previous" Button |
Screen A | Yes - probably re-labels existing Enter/OK button. Script sends KeyEnter to advance to screen B | No. |
Screen B | Yes - probably re-labels existing Enter/OK button. Script sends KeyEnter to advance to screen C | Yes - probably re-labels something like F12 to cause Screen A to be redisplayed (the 5250 application would need to support this of course) |
Screen C | No - Existing Enter/OK button is probably re-labeled as ""Save" instead. Script probably sends KeyEnter to advance to screen A to start a brand new order (after saving the current one). | Yes - probably re-labels something like F12 to cause Screen B to be redisplayed (the 5250 application would need to support this of course) |
If a pop-up message is displayed when leaving Screen A B or C
Sometimes a 5250 pop-up message is displayed when leaving Screen A, B or C (either by pressing F12 on System i or by selecting another object in the Framework) asking to confirm the changes, and the response to the message takes the user to different screens. For example if the answer is Yes the user might be taken to the nearest junction, but if the answer is No the user might be taken back to the entry screen (A B or C).
The easiest solution to this is to ignore the popup by defining it in newlook as a full display (see How to Turn Pop-Ups into Full Screens) and defining it to RAMP as a special screen. The script for the special screen can set the value of the Response field to Yes and send the Enter key. In this way, the assumption is that the user is cancelling the entry when they select something else in the Framework.
In addition a Cancel button on each of the entry screens can be set to send an F12 key to get to the special screen and back to the junction, and the pop-up can be hidden. Alternatively the Cancel button script for the F12 key could contain a javascript confirm() function, which will display a confirmation box to the user:
var answer = confirm("Confirm cancellation of changes?")
if (answer == true)
{
/* user pressed the ok button on the confirmation box to cancel, so send the F12 key */
SENDKEY(KeyF12);
/* if popup is defined as a special, let the special eliminate the screen */
HIDE_CURRENT_FORM("Entry successfully cancelled.");
}
else
{
/* user pressed the cancel button on the confirmation box, so don’t do anything */
}