Part 2: Event-Driven programming

By: John Kozacik


 * Component Programming and Digitalk's PARTS
 * Part 2 - Event-Driven programming

Introduction
This is the second in a series of articles on the component techology PARTS created by Digitalk. This article describes the architecture for event-driven applications, an architecture which was necessitated by the creation of the graphical user interface.

The first article in this series described Object Oriented programming, an understanding of which is necessary to put into perspective the benefits provided by Component technology. Reviewed briefly it said the following. Encapsulation, inheritance and polymorphism are concepts central to an object oriented language. They are used to describe the properties of objects and from them flow the sense of and rules for using programming constructs that represent objects in the real domain. Messaging is the means by which objects are manipulated programmaticaly.

A graphical user interfaces creates a change in the nature of the conversation that a user has with an application, and this creates an additional level of complexity in the nature of the control structure of the application. These two phenomena add a new context to the creation of applications to which OO may lend itself well. It should be remembered that this is a new field and is a practice rather than a science (see previous article). Thus there are many variations which are plausable in the design of architectures and the implementation of the technology.

GUI's
The user interface design common to DOS applications on the PC and 3270 applications on the Mainframe have the user communicate with an application via a command line on a display screen: the format presented by the application is a homogeneous 80 column by 24 row character-based display. Pioneering work done by Xerox transformed the screen into a display that could present an interface to an application which consisted of free-form grouping of data on the screen, delineated if necessary by graphical borders. This created the Graphical User Interface or GUI. Given this, textual and graphical information arranged on the screen to represent different contexts could thus be used to communicate application information to the user at a high level of informational content. Instead of providing input to the application through a command line, the user could use a device such as a light-pen, digitizer board or mouse to alow the user the ability to move an insertion-point indicator (cursor) and place information anywhere within the screen area. The amount of information presented by the display could be further increased by alowing one portion of information containing area to partially overlie the screen area of another information containing area, the most obvious metaphor to describe this representation here being that of the window. Sub-windows could be used to communicate with the user either in a smaller area of the screen or as a sub-screen (dialogue box) which presented itself appropriate to the user's actions. Items in the application could be visually encoded in the form of icons, whose appearance could be used to codify its content, increasing further the amount of information an application could present to a user. The end result of this experiment was to increase the conversationality of the user-machine interface.

Given the above it is a small step to present the results of several separate operations on a single display, each functionally independent from the other. However, if independent operations are to share the same display device, a common system would be needed to ensure that display of a window and display manipulations performed by a user on a window, such as moving a window, would not interfere with the procedure actually producing the information displayed in the window.

Managing this situation involves two sets of rules. One to control the display of information, the other to control the information produced by a single process. This resulted in a new program architecture which took the form of what is termed event-driven programming.

Event-Driven programming
The previous generation of programming effort involved a process orientation on the part of the programmer. In this type of thinking a program consisted of a single process, perhaps complex, but in essence unitary. The application was placed on the computer and the user would execute it to get, say a sales report.

With the facility of a GUI, a programmer could bundle a number of processes into a single application and let the user chose which was wanted, but much more importantly the programmer could create an application that allowed the user to provide control information to an application while the application was executing.

Utilizing this ability required a software foundation provided by the provider of the GUI, and a fundamental change in the way the programming process was perceived. Because of the increase in the number of things that were happening in an application (as noted above a GUI requires two kinds of control) the programmer loses a fair amount of control that he or she has over the operation of their application. If you develop a PL/1 program under MVS, at any stage in the running of the program you can get a snapshot of the data, from the input data, through the temporary files in the JCL, through any step in the program itself, and finally from the output data. In writing an application for a GUI, your code is imbedded in a complex set of software machinery which controls the display and execution of that code. Your code is not executed when the application runs, it is enclosed in a shell provided by the operating system and the OS/2 Presentation Manager that offers the user the option of executing your process. The security of the earlier sequential execution process for procedure oriented code gives way to a process that can make one feel he or she is placing their work in a bottle and tossing it into a flowing stream with the hopes that it will arrive at its destination safely. The nature of the code itself and the build process is more complex. As one works with this architecture the high degree of modularity becomes apparent. This architecture is effected by the particular GUI one is programming for. Fortunately, coding for the Presentation Manager of OS/2 is probably the most intelligible and most straightforward in the industry.

The Presentation Manager GUI programming environment causes the programmer to compartmentalize code highly. The typing of the compartments begins to make sense when the messaging nature of the Presentation Manager becomes apparent. The operation of the Presentation Manager is that of a continuously running cycle (diagrammed below) whose job it is to process messages which come from system and user events. The Presentation Manager architecture provides the means for your application to participate in the messaging scheme and offers conventions for making your application highly modular with respect to the roles it fills within the PM. Writing a program within the Presentation Manager and following the Presentation Manager conventions results in your program acquiring a particular (and sensible, once you get some experience) architecture of its own. However, this in no way limits what one can do programmatically; i.e., one has all the resources of the operating system at their disposal (named pipes, semaphores, memory management, etc.) as well as calls that can be made to the Presentation Manager for control of display. While there is an enormous breath to the Presentation Manager programming environment, it is highly structured and very intelligible. Simple gaining familiarity with the different features is the greatest concern here rather than wrestling with difficult concepts or arcane logic.

Event Driven and OO programming
How does this relate to OO? With respect to the PM, the object model is encouraged but not enforced. Because the architecture operates by messaging and because of its recommended programming conventions, it is object-oriented in nature. The System Object Model (SOM) is object-oriented. The Workplace Shell (WPS), which is a Presentation Manager application and uses SOM, can be written to. WPS programming enforces the object model, but that is beyond the scope of this article.

The kinds of calls that a Presentation Manager application can make are significant. In addition to function calls which are part of an ordinary application, routines can be created as Dynamic Link Libraries (DLL). Normally, all function calls are linked into a single routine to produce a load module. When the program is called, the entire executable is loaded into memory. Routines in DLLs exist in the parent code as calls that are resolved when the routine is called during execution of the program (dynamic linking). This means that the size of an executable which uses DLLs in its architecture and makes the calls to those DLLs as dynamically links will have a variable size in memory depending on which or how many of its DLL resident routines are called. Additionally, DLL routines are re-entrant: if there is a copy of a routine already in memory, that routine will be used by another executable saving memory space.

This use of DLL's by Presentation Manager applications has substantial development and maintenance benefits for the programmer and user. Since calls to DLL routines do not put such routines in the executable, the code in the DLL routine can be changed without re-compiling the executable. This is a substantial benefit for the developer since, with careful design, he or she can have a small mainline of source which may not need to be recompiled as each of its routines are developed and tested. For the user, upgrades can be constructed to require only the copy of a new DLL into a library to fix a bug or obtain a new version of a program. The Presentation Manager can also call SOM objects which are created as DLLs, adding the benefits of true OO to all of the above-mentioned benefits. The advantages of this will be considered in the next article.

Summary
The invention of the GUI gives the capability to provide more information and more conversationality for the user. It creates the need for a more sophisticated programming architecture. The OS/2 Presentation Manager architecture is not Object-Oriented, although it facilitates an Object-Oriented approach. Some benefits of Object-Oriented can be gained through the inclusion of SOM objects into Presentation Manager routines and through programming for the Workplace Shell.

The next article will rely on information and concepts in this and the previous article in this sequence to describe Component technology and the benefits it offers to application development.