29 July, 2006
last modified

The developers of the following, a medical application, decided to take a very aggressive approach to converting their applications to a Windows XP look and feel. Rather than introduce graphical display components to the users bit by bit, this developer has converted his programs to incorporate the AUI option in one undertaking. His firm felt that a measured introduction of AUI to their customers was NOT the best way to go, so they opted for the more dramatic approach.

Although they decided on a complete GUI transformation, they also decided to retain support for text mode, and that the best way to do accomplish that was by retaining the existing logic of the programs, adding "IF GUI..." conditional statements only as needed where the GUI presentation diverges from the text version.  So each of the following pairs of screen shots has been generated from the same program, the first showing the program running behind a conventional terminal (or emulator) and the second running behind A-Shell's AUI-enabled terminal emulator (ATE).

The GUI version of the login screen, shown below, uses a dialog box (corresponding to the text box shown above at the bottom of the text login screen) which is floating above a background window filled with the applicaiton logo (replacing the clunky SIGNIN banner). This is one example where the GUI presentation code deviates substantially from the text version, although the logic relating to the data entry is virtually identical.

In the first pass of converting the above main menu to GUI, the developer kept the identical design by very simply activating the automatic GUI enhancements in ATE (color scheme, beveled lines, proportional text) and by turning the boxes at the bottom into buttons and making all the menu selections clickable.

Later, it was decided that since the main menu is such an important part of the application, it was worth taking another pass at it, turning it into a floating dialog, putting all the menu pages into a TAB control, and adding some toolbar icons for the most typical options.

Here we have a straightforward conversion of a standard maintenance program. Since the programmer was already using boxes and "buttons" in the text version, it was trivial to convert these to Windows group boxes and buttons in the GUI version. The same INFLD calls are used for displaying and inputting the fields in both cases (with a single "IF GUI..." condition to activate some global options.).  Finally, the developer, being a programmer, couldn't resist adding a set of smaller toolbar buttons and a "lookup" button for the Acct field.

Here we have another straightforward text to GUI translation, similar to the previous one but illustrating a couple of additional INFLD features. One is that the State field, being limited to a reasonable set of possibilities, has become a combo box. The other is that Y/N fields in the Billing Information section have been converted to checkboxes. In both cases, this is handled by INFLD simply by invoking a TYPE code, without otherwise changing the program at all.

This pair of screens showing the two versions of the Patient Ledger illustrate one of the advantages of moving to a GUI, independent of mere vanity. As you can see, the GUI version below offers much more information than could fit on the text screen. Obviously additional program logic was needed for the GUI version, but unlike the thousands of lines of Basic code that would have been necessary to implement all of the features of the ledger "tree" control, a single powerful subroutine (XTREE) has taken care of almost all the details. The program just creates an array containing all of the transactions and passes it to the subroutine which handles all the interface details, including collapsing/expanding, sorting, justification, column sizing, repositioning, and even the pop-up context menu (displayed on demand when user right-clicking on a transaction).

This is a good example of something a "miracle" conversion from text to GUI can't possibly address, and where good old-fashioned tools such as powerful subroutines (full of parameters and cryptic switches) will ultimately be far more efficient than the supposed "plain English" commands that dreamers like to go on about.