Copyright © 1989, Dr. Dobb's Journal

Copyright © 1989, Dr. Dobb's Journal

Joseph Mouhanna and Michael Vose

Writing the user interface for a compiler imposes a different set of problems than creating a code generator. Presenting the applications programmer with an orderly set of windows and menus streamlines his interaction with the compiler. When designing this interface, the compiler's authors need to consider visual elements, and not machine internals.

A windowing user interface uses a limited number of variations on a few visual elements. These elements include windows, dialog boxes, and menus. When these components are analyzed, one realizes that dialog boxes and menus are specialized windows.

Therefore, a windowing interface lends itself to the hierarchical structure of object-oriented programming (OOP). The match between graphical user interfaces and OOP emerges because the techniques of OOP allow the creation of new windows as children of existing windows. Doing this requires little additional code. With a few generic window classes, specialized subclasses implementing variations on the overall window theme can be created.

Microsoft used QuickPascal itself to write the QuickPascal user interface. They did so to obtain the many advantages of OOP. In addition to code reusability, OOP techniques cut down on debugging and testing time. By mixing object-oriented and standard programming, Microsoft produced, in a short span of time, a user interface that will be easy to update for future releases of QuickPascal.

Good OOP design uses a top-down approach to creating programs. Objects are derived from general classes, and then inheritance is used to create ever more specialized child-class objects for special purposes. OOP's use of inheritance makes code reusable and, as a result, substantially reduces the size of programs. OOP techniques reduce debugging time by encouraging the use of hundreds of small, simple methods, rather than a few large, complex procedures or functions as in standard structured programming.

One or more parent classes for the application reside at the top of the OOP design hierarchy. The QuickPascal user interface uses a parent window class and a parent event-handling class. These parent classes contain the information and methods basic to all windows, as well as information about the event-handling functions of the user interface. The inheritance of these general qualities and actions by child classes allows the building of all the objects needed to implement a consistent user interface.

Child classes inherit the properties of their parents without the writing of a lot of additional code. Using classes and objects also streamlines event handling. Window environments written in classical languages usually use very large CASE statements to handle all possible events for each window type. Microsoft Windows applications, for example, frequently sport CASE statements with a dozen or more elements. An object-oriented event handler lets the different window types inherit all the general event handling characteristics of their parents, and only adds the new code needed to handle special events. This inheritance usually makes code much more compact and efficient than the more conventional programming approach.

However, this is not always true. A standard OOP event handler might send a "redraw yourself" message to a window previously covered by a dialog box or pull-down menu. QuickPascal does not always follow this standard approach for one simple reason -- speed. Instead, QuickPascal's event handler sometimes stores in a buffer a copy of the image that lies underneath the dialog box. When the dialog box disappears, the event handler transfers the image stored in the buffer back onto the screen.

QuickPascal uses this buffer-image technique to make its user interface more responsive. Redrawing an image from a buffer updates only the portion of the screen that has changed. Telling a window object to redraw itself means redrawing the entire image, which is much more time consuming. The buffer-image technique is an "optimization" of OOP practice.

This optimization addresses the few problems that result from using OOP techniques. If creating a class and an associated method to perform a task requires more bytes or machine time than a standard procedure, sticking with a more traditional procedure may improve a program's performance.

For this reason, QuickPascal's user interface does not use objects and their associated methods to the exclusion of standard procedures. Where standard procedures complete a task with less programming overhead than a method, QuickPascal's interface uses conventional procedures.

QuickPascal's user interface code uses two elementary classes. The subclasses used to spawn the objects that comprise the user interface are derived from these classes. One parent class receives information from the keyboard and mouse (input), and the other displays information on the screen (output). These two parent classes comprise the top of the class hierarchy.

The TApplication class is a good example of a parent class serving as the basis for other classes. QuickPascal's user interface declares objects from the child classes of TApplication, but does not declare any objects directly from TApplication itself.

When a window object of the TWindow subclass TDialogBox (or one of its descendants) opens, an object of class TDialogBoxAppli also opens to handle events within a dialog box. TDialogBoxAppli overrides its inherited GetEvents, HandleEvents, and DrawStatusLinemethods in order to handle events special to dialog boxes. TDialogBoxAppli also adds an instance variable that points to the type of dialog box created.

Dialog box objects from both window and application classes exist only as long as the dialog box remains open. When the dialog box closes, QuickPascal disposes of both objects.

Like TApplication, TMainAppli illustrates one of the principles of good OOP design. TMainAppli serves primarily as a foundation for its child, EditAppli, but remains general enough to allow for easy future expansion. If Microsoft decides to add another type of window to the QuickPascal user interface, TMainAppli will make it easy to add a new event handling class for that window.

EditAppli handles the bulk of the events in the QuickPascal environment. It keeps track of the number of open windows, plus the handle of the active window, and watches for menu activity. EditAppli's objects work with the window objects for TDocument, TMenuBar, and TSubMenu. EditAppli inherits almost all its methods and instance variables from TMainAppli.

TWindow and its child classes work in tandem with the TApplication classes. Every TWindow-derived object has a companion TApplication-derived object that handles the events for that window. A TApplication object can be associated with more than one TWindow object. TApplication and its children have instance variables that store mouse events, and timer events, and the current state of the keyboard. The children's methods acquire and dispatch these various events.

TApplication's child classes manage special event handling features (such as TDialogBoxAppli not allowing mouse clicks outside of a dialog box). TApplication, however, has methods to process all the normal user activities that occur in a window and passes those methods on to its child classes through inheritance.

The TApplication classes and TWindow classes work closely together. When QuickPascal opens and initializes a new TApplication-derived object and its corresponding TWindow-derived object(s), the methods set up a loop between the objects. The TApplication object's GetEvents method waits until either a keyboard or mouse event occurs. When something happens, GetEvents sets its instance variables and then ends. The TApplication object then transfers control to its associated TWindow object, activating its HandleEvents method. The TWindow-derived object's methods (My Window.LmousePress, for example) checks the state of the window's instance variables and responds to the event that just occurred. This usually results in a call back to one of the TWindow-derived methods, but can also mean transferring control to the compiler or to some other activity.

Copyright © 1989, Dr. Dobb's Journal