Screen Formats
These standards were developed to provide a consistent interface across all on-line transaction screens and to insure that only those features which are supported by the terminal and network interface are employed.
Screen Design
Use of Maps
All input and output screens in a NATURAL system should be implemented by the use of NATURAL maps rather that inline INPUT statements.
These maps should be created and maintained through the Map Editor. In this section you'll find guidelines for setting up profiles, creating maps and using these modules effectively in your NATURAL modules. If you need to review the procedures discussed in this chapter, we suggest you reference WH&O's NATURAL Developers Handbook or Software AG's NATURAL Reference Manual.
Map Editor
The NATURAL Map Editor should be used for creating all screen layouts. These rules should be observed when using the Map Editor:
+--------------------------------------------------------------------------------+
| 12:34:56 Define Map Settings for MAP 99-04-01 |
| |
| Delimiters Format Context |
| ----------------- --------------------------- ------------------------- |
| Cls Att CD Del Page Size ...... 23 Device Check .... _______ |
| T D BLANK Line Size ...... 79 WRITE Statement _ |
| T I ? INPUT Statement X |
| A D _ Layout ......... ________ Help Layout |
| A I ) AutoRuleRank 1 |
| A N ^ Case Default ... UC (UC/LC) Control Char . |
| M D & Manual Skip .... N (Y/N) Enforce Y |
| M I : Standard Keys .. N (Y/N) |
| O D + |
| O I ( |
| Filler Characters |
| ------------------------ |
| Optional, Partial .... |
| Required, Partial .... |
| Optional, Complete ... |
| Required, Complete ... |
| |
| Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12-- |
| Help Exit Let |
+--------------------------------------------------------------------------------+
Figure 19.1 - Map Settings Screen Viewed When Creating Profiles
Screen Layout
The screen size of the terminals to be supported is normally 24 lines by 80 columns. Screens in NATURAL are limited to 23 lines by 79 columns (message line reserved for limited use and screen attributes reduce the line size by a single column; this is generally true in the IBM environment). In addition, the following limitations should be imposed on the screen layout:
Note positioning of the optional command line. Only needed if a command processor has been generated and implemented in the application.
+--------------------------------------------------------------------------------+
| The message line is positioned here. | | 12:34 PM Centered Screen Title 99-04-01 |
| Second Line of Title, Centered MAP-ID | | ------------------------------------------------------------------------------ | | |
| |
| | | | | | | | | | | | | | | | | | | | | | | | | | | Command ---> | | Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12-- | | Next Help Main Prev Exit --- --- --- --- --- --- --- Undo |
+--------------------------------------------------------------------------------+
Figure 19.2 - General Map Layout
Screen Control
Input Statements
All maps should be invoked using the INPUT USING MAP statement. Input fields should not be specified as operands on this statement since they must be declared in a data area within DEFINE DATA.
The ALARM option should not be used. The WITH TEXT options should only be used in conjunction with the error message number as defined in SYSERR. The cursor must be positioned at the field in error:
REINPUT *1234 MARK FIELD *#FIELD-NAME
REINPUT with error message number 1234 and position the cursor to field #FIELD-NAME.
PF Keys
Program Function key facilities should be provided on all menus. Guidelines for selecting PF key settings focus on the primary "first" twelve PF keys. The suggested display guideline should look like:
+--------------------------------------------------------------------------------+
| |
| Command ---> | | Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12-- | | Next Help Main Prev Exit --- --- --- --- --- --- --- Undo |
+--------------------------------------------------------------------------------+
Figure 19.3 - Program Function Key Legend
Where the labels are actually initialized from within the NATURAL module using the map. This is accomplished with the SET KEY statement NAMED option. When creating and testing the map in the Map Editor, the option STD KEYS should be set to Y(es) and when tested will display as above but the labels will all appear as TEST.
ENTER
This key may be labeled only; program testing must be put in place to effect the action indicated by the label. The label is assigned, as: SET KEY ENTR NAMED 'NEXT'. In deciding to use this key, insure the setting is used through the application and perform the same function from within each program. Alternatives: CONTinue or MORE indicating continuation to the next display/input screen.
PF1
HELP - By positioning the cursor in a field on the screen and pressing the PF key to which this function is attached, the help routine/text attached to that field will be executed. If no help has been assigned but has been attached to the INPUTÉ statement, then the generic help will be executed. If no help is specified at either level, an error message is displayed.
PF2
MAIN - Returns directly to the main menu defined for the application.
PF3
PREV - Returns to the previous menu (program), that is, the program that invoked the program that display the current screen.
PF4
EXIT - is used to terminate the application.
PF5, PF6, and PF7
Available.
Guideline - In an application where multiple panels have been de fined and sent to the CRT in a single I/O, there should be an appropriate page manipulation command. Recommend assigning PF7 a - (minus) indicating scroll backwards (towards the top).
PF8
Available.
Guideline - In an application where multiple panels have been de fined and sent to the CRT in a single I/O, there should be an appropriate page manipulation command. Recommend assigning a + (plus) indicating scroll forwards (towards the bottom).
PF9 and PF10
Available.
Guideline - In an application where multiple panels have been defined and sent to the CRT in a single I/O, there should be an appropriate page manipulation commands. Recommend assigning a < (left arrow) indicating scroll one page to the left.
PF11
Available.
Guideline - In an application where multiple panels have been defined and sent to the CRT in a single I/O, there should be an appropriate page manipulation command. Recommend assigning a > (right arrow) indicating scroll one page to the right.
+--------------------------------------------------------------------------------+
| |
| Command ---> | | Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12-- | | Next Help Main Prev Exit - + < > Undo |
+--------------------------------------------------------------------------------+ Figure 19.4 - Program Function Keys Assigned For Physical Page Manipulation
Guideline - If the application has multiple panels. We recommend using PF9, PF10 and PF11 to shift between the three and the labels to read, for example, 'PNL1', 'PNL2' and 'PNL3'. Or, if the data is specific to each screen, giving the PF keys logical names like:
+--------------------------------------------------------------------------------+
| |
| Command ---> | | Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12-- | | Next Help Main Prev Exit Pers Auto Finc Undo |
+--------------------------------------------------------------------------------+ Figure 19.5 - Program Function Keys Assigned For Logical Page Manipulation
PF12
UNDO - Used to refresh/rebuild the screen with the original data. Usually the original object is re-invoked to restart the transaction.
All keys marked Available can be used for transaction specific functions. Program Function keys PF13 through PF24, the CLEAR key and Program Attention keys PA1 through PA3 should only be used with the approval of the Project Administrator.
PF13 through PF24
PF keys PF13 through PF24 can be made available through the execution of the Terminal Commands %YL (display the last 12 PF Keys) and toggled back by executing %YF (display the first 12 PF keys). This may require assigning two keys exclusive to the toggle control thus providing only 22 application (function) keys. See %YX in Chapter 18.
Menu Navigation and Program Control
A user may specify an action using one of the following methods:
Any screen where the user is required to specify a function or option should provide a menu and a corresponding code associated with each selection. The user will type the code of his/her choice into an appropriate input field (see Figure 19.6). Standard codes which should be provided on all menus are the EXIT and HELP options.
+--------------------------------------------------------------------------------+
| Message Line |
| 12:34 PM Centered Screen Title 99-04-01 |
| Second Line of Title, Centered MAP-ID |
| ----------------------------------------------------------------------------- |
| |
| Code Function |
| ---- ---------------- |
| A Add |
| C Change |
| D Delete |
| L List |
| ? Help |
| . Exit Application | | ---- ---------------- |
| Select Code: _ |
| |
| |
| |
| |
| |
| Command ---> |
| Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12-- | | Next Help Main Prev Exit Emp Auto Misc Undo |
+--------------------------------------------------------------------------------+
Figure 19.6 - Single Purpose Screen
+--------------------------------------------------------------------------------+
| Message Line |
| 12:34 PM Centered Screen Title 99-04-01 |
| Second Line of Title, Centered MAP-ID |
| ----------------------------------------------------------------------------- |
| |
| Code Function |
| ---- ------------------------------ |
| _ Employee Maintenance |
| _ Vehicle Maintenance |
| _ Miscellaneous File Maintenance |
| _ Description Maintenance |
| _ Transaction Processing | | ---- ------------------------------ |
| A Add |
| C Change |
| D Delete |
| L List |
| ? Help |
| . Exit Application |
| ---- ------------------------------ |
| |
| Command ---> |
| Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12-- | | Next Help Main Prev Exit Emp Auto Misc Undo |
+--------------------------------------------------------------------------------+
Figure 19.7 - Multiple Process Screen Example
Multiple Process Screen
In the Multiple Process Screen, several subsystems are displayed and the appropriate action codes are listed. The application module required should be marked on the left with the relevant process type, for example, to search through the Miscellaneous File, type an S to the left of Miscellaneous File Maintenance.
Optionally, selection keys, beginning values and ending values for specific searches may be added just above the PF key displays when required in more complex systems.
+--------------------------------------------------------------------------------+
| Message Line |
| 12:34 PM Centered Screen Title 99-04-01 |
| Second Line of Title, Centered MAP-ID |
| ----------------------------------------------------------------------------- |
| |
| Code Function |
| ---- ------------------------------ |
| _ Employee Maintenance |
| _ Vehicle Maintenance |
| _ Miscellaneous File Maintenance |
| _ Description Maintenance |
| _ Transaction Processing | | ---- ------------------------------ |
| A Add |
| C Change |
| D Delete |
| L List |
| ? Help |
| . Exit Application |
| ---- ------------------------------ |
| Search Key _________ Start _________ End _________ |
| Command ---> |
| Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12-- | | Next Help Main Prev Exit Emp Auto Misc Undo |
+--------------------------------------------------------------------------------+
Figure 19.8 - Multiple Process Screen With Optional Input Fields
Add
The add screen will be displayed with either no fields ( if the Search Key was not typed into the menu) or with the key field from the menu displayed and protected. Once the fields have been filled, pressing the ENTER key or a PF key assigned to confirm the addition, will add the record to the database and display a blank screen for further processing. Pressing PF2 will return to the main menu, PF3 will return to the previous calling screen or menu.
Change
The change screen will be displayed with either no fields or with the requested record. Once a field has been filled and validated, it is protected. All other fields will be modifiable. The database will only be updated by pressing the ENTER key or a PF key assigned to confirm the change is pressed. (If PF4 (REFRESH) is pressed before the CONFIRM key, the original data will be re-displayed).
Delete
The delete screen will display the data for the record to be deleted as retrieved from the "SEARCH KEY" value after the key has been validated. All fields will be protected. The record will only be deleted after pressing the CONFIRM key.
Inquiry
The inquire (search) key value will be validated and the relevant record displayed with all fields protected. The CONFIRM key will not be available, but the MAIN and PREV assigned keys will be available.
Search
Search screens, when incorporated into the application structure, should be kept simple and employ the same codes as with other screens, that is to say:
If any valid action is typed next to the requested function, pressing the ENTER key or another key assigned the CONFIRM function will cause the appropriate action to be executed. As is our standard, all the selection fields will be filled with periods.
It is suggested the when the end of the data is encountered when scrolling forward, an "END OF FILE" message should be displayed.
Screen Attributes
NATURAL Attribute Definition
Screen attributes allowable in NATURAL programs are mainly determined by the range of attributes supported by the specific terminal.
Other attributes such as a mandatory field and field length characteristics (AD=E or F or G or H or selected combinations of these attributes) should not be used, making these checks under program control.
Allowable attribute definition (AD=) parameters include:
|
B |
Blinking Default Intensity Intensified (Highlight) |
|
L |
Left
Justified Right Justified Left Justified Numeric, Zero Filled |
|
A |
Input
Field Output (Protected) Field Modifiable Field Temporary Protect |
|
Y
|
Assign Attribute Control Variable (see next section) |
Attribute definitions dependent on hardware characteristics should be avoided to maintain a high level of transportability of the software. (This should also be the rule when incorporating color attributes in screens). These attributes include:
|
V |
Reverse
Video Underline Cursive (Italic) Display |
|
T
|
Translate Lower to Upper Case |
Further details on AD parameter values can be found in the Software AG NATURAL Reference Manual and WH&O's NATURAL Developers Handbook.
Attribute Control Variables
The need to test whether a user has modified a field on the screen is determined by utilizing an attribute control variable. This variable (associated with a C format) must always be used when assigning the temporary protect option during screen validation.
Dynamic Attributes
The DY parameter, used to define dynamic attribute definition, should not be used for interactive data processing. Reserve these functions for the Attribute Control Variable.
The Dynamic Attribute is an excellent choice when processing textual data because of its ability to provide more dramatic displays. It is a very good tool to use when variables are inserted into screen fields as headers and field prompts and the characteristics of one or more words needs to be set.
Screen Data
Special Characters
There are several characters which have special significance within the NATURAL development environment. Developers and programmers should be aware of their use and avoid using them where potential conflicts between the environment and the application might arise.
Terminal Control Character [%]
The Percent Sign identifies a Terminal Control Command and should never be inserted in any data input by a user.
Help Character [?]
The Question Mark is used to invoke a help member: HELPTEXT or Helproutine. Placing the question mark in the first position of a field and pressing the ENTER key will invoke the help member attached to the field through the HE parameter.
Upper and Lower Case
Lower case characters may be used in screen headers, messages and any output only text.
Lower case should not be used for any input of descriptor data due to the problems of matching upper and lower case string in ADABAS, that is, smith or Smith does not match SMITH. However, it is acceptable for ordinary non-descriptor fields.
Output Data Format
Output Only Fields
Output only fields should always be protected (AD=O will perform this function on NATURAL screens). Data should be justified per the default for the specific format, that is, alphanumeric should be left justified and numeric data right justified.
Modifiable Fields
When a modifiable field contains existing data, the data will be displayed with the justification specified for output only fields, allowing the user to over type the data.
When a screen of data is first displayed, all modifiable data should be displayed at normal intensity. During validation and/or verification of data, error fields should be intensified and the cursor placed in the error field for correction. When a field passes verification, it should be protected on a temporary basis until the screen is ready to return control to the program. Temporary protection is assigned through an Attribute Control Variable.
Input Fields
Input fields and modifiable fields which contain no existing data should have the fill character set to underscores. This may be done during Extended Field Editing or with the Delimiter Settings screen when in the Map Editor and through direct assignment of the fill character inline with AD='.'. This will indicate to the user the length of the field (if there are field values displayed, the fill character will fill the remainder of the field for the user).
Editor's Note on fill characters: avoid underscores on monitors that tend to "bleed" into solid lines; don't use dashes or hyphens in fields where hyphenated data is requested; avoid the period in numeric data where input of a decimal position is required.
Map/Screen Sizes
Generally, maps should conform to the physical screen size, that is, 23 by 79. The use of long and wide maps should be avoided as data entry screens as problems have been known to occur when an error is created on a part of the map which is not being displayed on the terminal.
Maps may be used to define report layouts taking all the formatting out of the program code and into the friendly Map Editor with all its layout capabilities. Potentially, maps created for batch environments can be more easily converted to on-line inquiry.
Maps of varying sizes, particularly those smaller than the physical terminal screen, can be effectively used with windowing techniques; pop-up help is a good example.
Editor's Note on large maps: wide maps, 23 by 240, do provide a effective means of sending three "screens" to the terminal where the user will use PF keys to display each logical screen. Opponents of this technique will argue over its I/O overhead so check with your systems staff for a reading on this issue.
Processing Rules
These are verification rules coded within the map itself instead of within the application program. Coding of these rules must be a coordinated effort and managed carefully.
There are two types of verification specified through the use of Processing Rules: PF Key verification and field verification.
The PF Key rule will validate that only the allowed PF Keys are used and that they conform to the appropriate application function. This rule will apply to the Map as a whole rather than to individual fields.
Field verification should cover the following conditions: range checking, value validation and syntax checking.
Note: Rules should be self-contained. Accessing an ADABAS file or an external table from within a Processing Rule are acceptable techniques but executing external object should be avoided: FETCH, FETCH RETURN, CALLNAT, or PERFORM for example. There is a high potential for having control passed out of the map before all verification is completed.
When a particular Processing Rule is considered common to several maps, it may be defined in PREDICT to be included at map creation time. However, there are cases when the rule is not wanted in the map. If the rule code has been amended in PREDICT, it could cause execution time errors. A solution to this problem is to bring down the rule from PREDICT and then amend the code accordingly within the Processing Rule Editor within the Map Editor after first U(nlinking) the PREDICT rule. The coding of the rules in PREDICT and the attaching of rules to fields should only be authorized by the Project Administrator. Processing Rules directly linked to individual fields of a file are not, currently, recommended.
PREDICT is a rigidly controled resource in many environments. An alternative method of provide "common" processing rules is through a copycode object. A processing rule may be saved from within the Map Editor; they are stored as copycode (source only). Incorporate the code into other processing rules using the ".i" command.
Where input fields are validated within a program followed by REINPUT to notify the user of any errors, the amount of validation processing should be kept to a minimum.
All fields that are to be validated should be checked beforehand to insure that they have been modified before any validation takes place. This is particularly relevant if the validation process involves large amounts of CPU (intensive) processing.
NATURAL Output Facilities
Pop-Up Windows
Pop-up windows are small framed windows that are temporarily superimposed on a screen of data to provide additional information without destroying the current contents of the screen. The use of pop-up windows in the system is recommended for providing help information for particular fields on a screen. These would be invoked from the help member attached to the (screen) field. Since the content and position of a pop-up window will vary according to the field, no set rules for their size and position will be specified. However, a pop-up window should not occupy more than half the screen and should not overlay information relating to the context of the window.
Windowing
Windowing allows the use of logical screen sizes larger than the physical screen size supported by the terminal. This can be useful for displaying reports normally formatted for the printer (132 characters wide) on a terminal. The user is provided with a mechanism for scrolling the physical screen window across the logical page.
Use of windowing should be discussed with the Project Administrator before incorporation into the application.
Non-Conversational Writes
The non-conversational write facility in NATURAL, invoked by the %N Terminal Command, allows a program to send output to a screen without waiting for a user response (usually by pressing the ENTER key). This is a useful technique for informing a user of the status of a particular process or function which may take several minutes before providing a response. Its use is recommended for any transaction which may take more than a few seconds to complete.
An alternative use involves windows used to display and accept data. The user will be required to press the ENTER key once to exit a window into which he/she has just entered data. The data is inserted into the field on the original screen and the user must then press the ENTER key to return control to the NATURAL module. If needed, code a SET CONTROL '%N' statement to pass through the original screen (depositing the field value from the window into the field in the map) and directly into the NATURAL module.
Report Format
Overview
This section is intended to form the proposal for report design standards for use with NATURAL.
Assumptions
It is assumed that standard computer stationery will be used for reports. This therefore provides a maximum report size of 132 characters on 66 lines of output.
Report Design
Every production report output should use the WRITE USING FORM statement. Therefore every report must be defined using the Map Editor.
Each page of the report should show the following information:
+--------------------------------------------------------------------------------+
| |
| 1 | | 2 | | 3 application/system name | | 4 progname report title yy-mm-dd | | 5 report title Page 1 | | 6 ---------------------------------------------------------------------------- |
| 7 | | 8 |
+--------------------------------------------------------------------------------+
Figure 19.9 - Report Headers Guidelines
For every page that is produced, the first two and last two lines should not be used. The body of the report will contain 58 lines per page.
An '*** END OF REPORT ***' or similar type of message should be produced as well as details of the number of errors (if applicable) on a separate page (use NEWPAGE for this function in the NATURAL object).
The data for the report should be laid out in such a fashion so that it is easily readable without wasting space on the page.
2 ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™ ™f ™ ™ ™ Dreamweaver 2ƒÄ8A¼ 2 STR ¿ôÿÿ ›î¨