The Ideal Screen Editor

VECTOR Vol.7 No.4

The Ideal Screen Editor

a talk given to the BAA November 1990 by Anthony Camacho

Five overhead projector foils were shown as an introduction to the screens which made defining a screen easy. Foil 1 was an introduction.

WHY A NEW SCREEN SYSTEM? [foil 2]

Most applications need one Vendors’ systems incompatible Takes too long to write Wish to make APL Wish to restore APL’s advantages Wish for screen to respond fast Cannot spare much workspace

The motives for writing a screen system were to provide something independent of vendors that required as little beyond ISO APL as possible, written in APL so that anyone could amend it and straightforward enough to be used without a great deal of effort. Once, APL gave its users the best interface for interaction between the keyboard operator and the system; it would be nice to restore the advantage. Also a system would have to be fast enough and use little enough workspace so that it would be practical even in I-APL.

BDRDD ORIGINS AND THE IDEA {foil 3]

Paul Chapman’s port from Viz::APL Use only window get/ put cursor All screen input/output is character Pre-calculate variables for speed Hold items on file to reduce space

To use: R«SNAME AFS CHARVEC SNAME «<+screen name on file CHARVEC ++chars for fields R «> chars from fields

78

VECTOR Vol.7 No.4

The idea was that adequate screen be written using only four special functions, which are available in most versions of APL on micro- computers. The originator of the idea was Paul Chapman, who had to port a system from Viz::APL to APL*PLUS/PC in a hurry. He never completed or he wrote, but it was in daily use for several years and the response was adequate even on an 8088 at 4.77MHz. Most data was held in vectors and as much as possible was pre-calculated. I learned about it by having to enhance the system that used it and the Ideal Screen Editor (ISE) was born when I considered how Paul's screen system could be adapted to meet the objectives mentioned.

The main ISE is that all input and output of the screen display functions is in characters. The file referred to on the foil is ASTIE. A secondary limitation is that the main function 4FS has to call subsidiary functions for any field which has more than one line.

FEATURES OF THE DESIGN [foil 4]

Three functions for simplicity

AFS Full screen (many fields} AMA Matrix amend (one fld only) ABB Bounce bar (one field only)

AMA & ABB handle multi-line fields

For each AF‘S the file has 9 components

The subsidiary functions are AMA which displays any matrix for amendment in a window (which may be a pop-up window) and ABB which handles the bounce- bar method of choosing an option; the choices may be scrolled past the window and selected with the highlight bar or, if the lines are numbered, by entering the option number.

The pre-calculated held on a component file (or a pseudo- component file) in nine components, containing:

The design so that it can be re-entered with variations The window for The initial contents of the screen The indices of the characters that may be varied The attributes of the initial contents ae Yh

79

VECTOR Vol.7 No.4

table giving details of each field Asmail matrix of executable lines (mainly standard validations) A vector of the codes from keys that cause special actions A corresponding character vector of labels (the action for the key) eo ONS

The field table contains the window for each field, the navigation from field to field, three attributes of the field:

on display, when highlighted with the cursor in it and when validation has failed and it must be re-entered.

It also contains a pointer to the validation required, a pointer to any special action required on moving the cursor into the field, and, for multi-line fields, details of what is required.

To get the system into use, once it was established that it was feasible, the author had to do three things:

1. Produce an example to show how to use the screen functions 2, Demonstrate that the system was robust with a demanding test 3. Provide the potential users easy way of entering screens

These three needs could all be met if the screen system could prove its worth by using it to write the screen entry system. The screen entry system is the most important part of the design. If it is really easy to use then people may use it even if other features are less than perfect. On the other hand if the entry method is difficult to use then it probably will get ignored.

The author’s purpose this afternoon therefore was to describe the entry procedures and to ask the BAA members present whether they could think of a simpler way of doing any of the are an essential part of entering a screen design.

WHAT IS THE EASIEST WAY? [foil 5]

Enter by amending a similar screen Defaults (sensible) for everything Never a need to count (characters) Specify position by cursor Choose from lists where possible Show effects as soon as possible Allow easy corrections

80

VECTOR Vol.7 No.4

The simplest way to enter a new screen design would be to amend one which was similar. It is easier to alter a heading and an instruction or two than to key in a complete design. The simplest way to enter colours, validations, field sequences and the action to be taken on each kind of key depression is to have them all default to standard settings. The standards to which everything defaults should themselves be settable so that all the screens in an application can be given a distinctive house style. At every stage the delay between specifying something and showing the result should be as short as possible and the sequence to respecify needed should also be short and quick.

A series of draft screen designs were then shown and the proposed method of use for each described. In every case the aim was to entry method which would give the least trouble to the keyboard operator entering the design.

specified by putting special characters at the ends of the field (outside it so that default contents could be entered within the field). Ruled lines are specified by their ends, boxes by their corners and multi-line fields by marking the first and last lines after the fashion of single fields but with special characters. The screen may be framed with single or double lines by entering +  or #  in the top left corner.

Pop-up fields are specified by moving the cursor to the top left, marking the spot, and then to bottom right and fixing that. The same procedure is used to specify colour for the areas of the screen outside the fields. Fields themselves have three colours; all may be left to default values, the defaults may be changed and any field may have special colours set by moving the cursor into the field and specifying

Validations are specified by entering a character corresponding to one of the six standard validations or to a special validation in the field. If a special character is used then the validation required is entered as a line of APL (best to give a function name) which returns the validity as a boolean.

The fields may be navigated in two sequences and there is a third sequence for inserting the variable data into fields. The sequences have defaults. The default for any sequence may be amended by entering a decimal number in a field to give its new position in the sequence (like inserting a line under the del editor). On moving the cursor from the field the new sequence is calculated and displayed.

The allocation of actions to keys is done by displaying two bounce-bars. In one the key and a two letter code for its current action is shown; in the other a list of

81

VECTOR Vol.7 No.4

possible actions is shown. To allocate a different action to a key, first highlight it, then highlight or enter the new action, then press an F-key.

During the discussion afterwards only one improvement to ease of entry was proposed, by Peter Branson. Peter suggested that the method used for specifying field should be used to specify multi-line fields. The author was glad to accept it and hoped that, as nobody could think of any further improvements, the design was now as good as it could be.

APL.68000

Level Il APL.68000 Level Il is a full specification APL2 for the 68000 family of processors. It incorporates all the user- oriented enhancements of APL.68000 Level | as well as MicroAPL’s acclaimed windowing interface. APL.68000 Level Il is available for computers such as the NCR Tower, Sun, HP, Bull, Nixdorf, Wicat, Mac, Amiga and ST. Features include:

Nested and mixed arrays User-defined operators Selective specification Upwards compatibility with APL.68000 Level |

For more details contact: MicroAPL Ltd., South Bank Technopark, 90 London Road, London, SE1 6LN. 071-922-8866

82