BAA-GUI Workshop APL*PLUS II Sessions

VECTOR Vol.10 No.3

BAA-GUI: APLs and The Windows GUI APL*PLUS UISessions There were three speakers in the APL*PLUS TI stream of the BAAGUI Workshop. Peter Day with interjections from Dave Phillips both of Cocking and Drury, Duncan Pearsonof Nestlé-Rowntree, and Dave Piper of Eagle Star.

Peter Day and Duncan Pearson notes by Anthony Camacho Peter Day of Cocking and Drury introduced us to the interpreter and the differences between version 4.0 and 5.0. APL*PLUS III will be in a different league and will not be fully upwards compatible. It will only work on 32-bit machinesand will nottry to run the OWIN or OWGET or OWPUTfunctions weall learned in APL*PLUS/PC. To make conversion to PLUSIII easy one should be prepared to replace these andall the DOS-dependent features such as [CMD, OINKEY, OARBIN, (Gx(anything), all the peeks and pokes, the printing methods andso on.

In APL*PLUSII version 5.1, which we used for the day, there is a function Win whichsendsits right arguments to an APL*PLUS Agent which runs minimised under Windows.This agent is what actually communicates with Windows.

Duncan Pearson explained that if you adopt the procedures recommended by Manugistics, each object (form, key, radio button, edit box, label, combobox and so on) requires a one or twoline function to be created. A workspace with say 20 forms each with twelve objects on it would require a workspace of over a thousandfunctions and as these are created automatically and have long names (madeup of the namesoftheir elements) maintenancegets to be very tedious. Instead he and Adrian Smith have devised a tabular way of recording and implementing the object. The details are entered into a ten column matrix (a nested array) per form wherethefirst line defines the form and the subsequent lines defines the objects in it (which are sometimes, confusingly,called controls).

An advantage of this approach is that there is a single nested matrix for each form in the workspace. The workspace is not cluttered with hundreds of functions.It is then possible to write utility functions to display and amend the objects of a definition matrix. This makes the workspace much easier to understand and to maintain, as a print of each definition matrix effectively summarises the windowsinterface of the workspace.

57

VECTOR Vol.10 No.3

Wespenta large part ofthe afternoon trying to constructa definition matrix fora form to collect or amend name and address records. It had to have appropriate fields for name,initials, the lines of the address including country and zip or postcode, some other details such as a classification, telephone numberor email address and the necessary keys and buttons to look people up, add, amend or delete them.

It is a tribute to Duncan's exposition that some people actually got something working before the exercise was broughtto a halt to allow Dave Piper to show us a different method of overcomingthe difficulties in using APL*PLUSII under Windows.

David Piper of Eagle Star Notes by Duncan Pearson David Piper of Eagle Star showed us a completely different approach to the interface with windows. Instead of using all the support functions in the APLGUI workspace to define and create his windows,he uses a standard dialog box editor to define the boxes and a few quite simple windowsroutines to read them off a resourcefile and define them. He showed usa small application built using these tools, a PC/Mainframefile transfer utility that unsurprisingly did not haveits full functionality, but which showed the userinterface well. Then he gave a presentation of his design objectives and implementation details, which wasa setofslides each of which wasa dialog box run byhisutilities. The result was very fast and looked easy for the application developer to use. Howeverit obviously could not have been done without the system programmer (David) knowing a fair amount about Windowsdialog box classes.

The process of defining windows interactively at run time, which is how the APL*PLUS If APLGUI doesit, is horrendously slow. Windowshasto allocate resource individually for the form and for each ofits controls (buttons, edit fields, scroll bars etc.) at the time of creation. Howeverthereis a class of window available whose definition contains the definition of all its controls and the creation of which is very fast. This is the dialog box.It is little restricted in that it can contain only 255 controls, but obviously this design constraint is far outweighed for David by the speed ofcreation andtherelative modularity of the code needed to manageit. It is also not possible for the APL program to change aspects of the definition (e.g. the height, width and numberofedit fields) at run time.

The standard procedure with compiled languages is to define the dialog box with a resource editor and then store the compiled definition, firstly into a

58

VECTOR Vol.10 No.3

resource file and thenfinally into the application s executable file. Instead of using a windowscall to create each control in the box the application uses one call giving the nameof the dialog box within the executablefile; at which point windowscreates the whole dialog box andall its controls in onefell swoop.This process is effectively what he has enabled his application developers to do from APL. He has produced a small set of APL utilities that read a dialog box definition from a resourcefile, call the windows function to create the dialog box from the definition and associate APL expressions with events on the dialog box.

The window definition is done in a standard dialog box editor from the Software Developer s kit or from Borland Resource Workshop. The result is saved to a resource file (with extension .res) and when neededthe definition is read from the file into the workspace using UNREAD and then used in a windowscall to create the dialog box. Thecall is fast becauseall the hard work is done by the dialog box editor. Furthermore, as the definitions are held on file and only retrieved when they are needed for creation, it is possible to have the resource editor running at the same time that the application is running and to make small changes to the appearanceofthe boxes withouthalting the APL execution.

For a production system in which no changeto the dialog boxesis envisaged the definitions can be compiled into the APL Agent executable file (the windows task that communicates with the APLinterpreter) by the SDK resource compiler. This reduces the number of application files and meansthat the definition need no longer be read from file and passed to the create dialog box API routine. Instead slightly different routine is used that is passed the nameof the box, whichit then reads direct from within the Agent. This saves even more time as the definition does not have to be read from file.

The behaviour on a user interacting with a control is defined using the APLWIN function W_CreateFilter, which associates a line of executable APL with a windowsevent, on a control. Whenever the event happensto thecontrol the line gets executed. This is very flexible in contrast to the APLGUI where one needs to have one function per event per control perform, a restriction which can cause a vast numberofoneline functions in the workspace, but which will however be lifted in APL*PLUSIII. It also gives access to all the messages that Windows passes instead of having themfiltered by a well-meaning middle layer.

To conclude, this is a goodfast solution to the problem of the Windowsinterface from APL*PLUSII. It will be interesting to see if APL*PLUS III addresses the problem of speed and modularity to the extent that David thinksthatit is viable. There is no doubt though that he feels happier working close to the metal and relying on his own code. The results werecertainly impressive.

59