WebTerm Dynamic GUI Front-Ending
The WebTerm API provides a system that allows other programs to actively monitor terminal sessions for the purpose of delivering richer content. The traditional terminal window or “Green Screen” may or may not be visible to the user, depending on the particular implementation. One common use of this system allows scripted programs in web pages (typically written in JavaScript), to actively monitor the terminal session and present a modernized, more sophisticated front-end to applications residing on a midrange or mainframe computer without displaying the raw terminal screen.
Download a pre-configured sample for 5250 to an AS/400 with the necessary html files. You may use the html as templates and review the JavaScripting that makes this possible. All images, logos, text, html, and JavaScript copyright Powerlan USA, Inc. All rights reserved. You may use the html and JavaScript to create your own front end, replacing the graphics with your own.
WebTerm’s front-ending system allows programs to monitor terminal sessions through calls to the WebTerm API, which has functions (also called “Public Methods”) designed specifically for this purpose. As a program is alerted by WebTerm that the session has changed, it updates itself accordingly. Dynamic screen monitoring can be accomplished using three basic functions in the WebTerm API:
GetTerminalLine Reads screen data for one or more terminal lines
TerminalStatus Provides current screen status
GetEditFieldList Describes the set of edit fields currently displayed
These functions are described in detail in the Chapter 4 of the WebTerm 2.0 Manual. (Not published yet)
Sample Implementation
A basic implementation of this system is available to all WebTerm licensees in source form for adaptation and enhancement, and will be made available online for demonstration in the near future. In the meantime you may contact info@powerlan-usa.com to schedule a one on one demo.
TerminalStatus()
Purpose: Use this function to determine the current status of the terminal session
Parameters: None
Returns: A string in the following format: “{rows,cols}time”
- - The substring {rows,cols} describes the current terminal dimensions, in rows and columns. Some terminals support dynamic size changes (for example some 5250 terminals can switch between 80 to 132 column modes.
- - The “time” substring describes the status of the data on the screen. It will contain one of the following, depending on the current status:
- “busy” means the terminal is waiting for an update from the host (as a result of typing Enter, for example), and hence that updating is not currently required
- “error” means that an error has occurred in the terminal, and that the error will need to be handled before continuing
- any other value than those described above should be interpreted as a value which, if different from the previous call to this function, asserts that the screen has changed (and presumably, that updating would be appropriate)
Example: returnStr = WT_Terminal.TerminalStatus();
Usage Notes: The following is an excerpt from a web page that checks the terminal periodically for status changes. After calling TerminalStatus(), the JavaScript function separates the returned string into three sub fields (see bolded below) for further processing.
function PeriodicScreenCheck() {
if (typeof WT_Terminal == undefStr)
return;
returnStr = WT_Terminal.TerminalStatus();
commaLoc = returnStr.indexOf(",");
endLoc = returnStr.indexOf("}");
rowStr = returnStr.slice(1,commaLoc);
colStr = returnStr.slice(commaLoc+1,endLoc);
thisUpdate = returnStr.slice(endLoc+1);
if (thisUpdate.indexOf("busy") != -1)
thisUpdate = "busy";
else if (thisUpdate.indexOf("error") != -1)
thisUpdate = "error";
if (thisUpdate != lastUpdate)
lastUpdate = thisUpdate; // TIME TO UPDATE!
}
GetEditFieldList()
Purpose: Use this routine to get a list of the editable fields on the terminal screen.
Parameters: None
Returns: An array of variable length, containing fixed-length (5 byte) records in the follow format:
StartRow, StartColumn, EndRow, EndColumn, FieldType
StartRow and StartColumn describe the start of the edit field
EndRow and EndColumn describe the end of the edit field
FieldType describes the type of edit field (see “Usage Notes”)
The records are in order as they appear on the screen, with rows being more significant (e.g. a field starting at column 5 of row 3 would be found in the list before one starting at column 2 of row 4).
Example: returnStr = WT_Terminal.GetEditFieldList();
Usage Notes: Fields can start and end on different rows, and thus it is also feasible that a field could end in a lower column than it starts (e.g. from column 75 of a row to column 20 of the next row)
FieldTypeBits_Edit1 = 0x01; // Edit Fields 1-3 (see below)
FieldTypeBits_Edit2 = 0x02; // " "
FieldTypeBits_Edit3 = 0x04; // " "
FieldTypeBits_Hidden = 0x08; // for passwords, et al
FieldTypeBits_AutoEnter = 0x10; // send an enter when filled
FieldTypeBits_Reverse = 0x20; // Reverse Video
FieldTypeBits_TBD3 = 0x40; // undefined
FieldTypeBits_TBD4 = 0x80; // undefined
These values describe the values of the Edit Fields 1-3, as described above. So, ANDing the FieldType byte with 7, will yield one of these:
EDIT_AlphaShift = 0;
EDIT_AplhaOnly = 1;
EDIT_NumShift = 2;
EDIT_NumOnly = 3;
EDIT_Katakana = 4;
EDIT_DigitsOnly = 5;
EDIT_IOInput = 6;
EDIT_SignedNum = 7;
|
