The A-Shell User Interface (AUI) toolkit encapsulates A-Shell’s user interface functions within a framework that simplifies the addition of a graphic user interface (GUI) to legacy text applications and promotes the separation of business and presentation logic. The functions are accessed from A-BASIC via subroutine, XFUNC, and/or AG_xxx statements, but may be conceptually thought of as a series of object classes and methods which can be extended by application programmers through creation of higher level SBX routines.

AUI supports many of the standard GUI objects that Windows programmers are familiar with (buttons, dialogs, list boxes, etc.), but is designed to help bridge the two major gaps that divide legacy A-BASIC programs from their modern Windows counterparts:

•   Fixed pitch, 24 row by 80/132 column screen vs. proportional font, pixel-level, variable sized windows. AUI deals with this by maintaining two display layers: a text layer (for traditional fixed pitch text) and a GUI layer (for controls), which share a common row/column coordinate system. The GUI layer is transparent, except where controls are placed, and acts as an overlay to the text layer, allowing text and GUI objects to appear to coexist on one screen.

•   Procedural vs. event-driven programming model. AUI converts keyboard and mouse events into special keyboard strings that INFLD, AUI_EVENTWAIT and any other input routines can interpret. By selectively defining keyboard strings for individual objects, and choosing which codes your input routine(s) will respond to, you can determine the degree to which each program assumes a traditional linear or more modern event-driven behavior.

Since the AUI toolkit is primarily just a repackaging of existing functions and intrinsic language functions within one or more "wrapper" subroutines, one might wonder what is the point. Although it is true that repackaging doesn’t provide any new functionality, it does provide the following advantages:

•   It helps organize the documentation, especially for the GUI functions, since they are logically grouped together (rather than being all over). This is especially true for people just getting started.

•   It helps organize any changes to your programs by making it obvious which parts are specifically related to the user interface logic.

•   The natural architecture of subroutines is the closest thing to object orientation we have in A-BASIC. The are truly modular, they encapsulate details within an explicit interface, they do not support any global variables (which is one of .NET’s requirements), they are extensible (via the SBX mechanism) and they can be substituted (via the ALIAS or VXCALL mechanisms), all of which contributes to good program design.

•   By submitting to the discipline of implementing all of your user interface code within a manageable set of routines, you will create a better logical separation between your business logic and interface logic, and will be better positioned to adapt to new interface environments in the future. (Or, for that matter, to support the legacy text interface as a variation of a more object-oriented graphic user interface.)

Although not (yet) fully realized, one of the goals of the AUI concept is to shelter the business logic of applications from the low-level details of the capabilities of the display device. Before adopting any of the functions described herein, check the documentation to determine the extent to which the function requires or assumes particular display environment characteristics.