LHAPI Overview
LHAPI is like other Graphical User Interfaces (GUI's) in that it provides functions for directly manipulating the display, and windows (a.k.a. "objects") that are used to interact with the user. A typical LHAPI program will create a main window, and then based on interaction from the user, create dialogs. These dialogs will consist of controls that the user will manipulate; the program will then use that input accordingly. LHAPI is designed to operate on a limited-space machine, so unlike other GUI's, the application is held responsible for more of the work in getting a window up and running.
Although not strictly object-oriented, does LHAPI does communicate between windows with messages. These messages are used to tell, for example, an edit window to accept a keystroke, or for a list box to redraw itself, etc. Like OOP, LHAPI objects can be "reused" by subclassing the object and adding/removing functionality. An example of this might be creating a date-only edit field by subclassing the edit field, and adding the ability to parse dates.
An application under LHAPI is event driven--it operates on messages generated by the user. These messages from the most part come from the user (which come in turn from the System Manager). Thus, a LHAPI application consists of three primary parts:
- The Event Loop. The application needs to get messages from the System Manager, and feed them to LHAPI. This portion of an application is relatively standard; E_KEY events from the System Manager are translated into KEYSTROKE messages sent to the focus window, etc.
- The Window Handlers. The application itself consists mostly of a Main Window. The handler for that Window (i.e., the code associated with maintaining that window) is the thing that distinguishes that application from all others. Windows handlers are needed for processing input from dialogs, or for creating specialized classes of control windows that LHAPI does not directly support.
- The Window Data. Every window created by LHAPI requires a window structure. This window structure is allocated by the application; a pointer to a window structure is the way that LHAPI typically refers to a window (analogous to a "handle" under other systems). Many times, other associated structures are needed to maintain a window. These include information directly related to the window such as edit buffers, places to store radio button/checkbox selections, but also include menu and function key structures. Much of the "flow of control" of LHAPI applications is embedded in menu and function key structures, since these allow different sets of user actions associated with windows coming in and out of creation. For example, a main application may have ten specialized functions on the function keys, but when a dialog comes up, only OK and Cancel are available. This is automatically handled by LHAPI by setting up different function key structures for each window.