In order to begin developing GUI COBOL applications in the Windows environments, it is important to understand the concept of event -driven programming.
While the term ‘event driven’ may be somewhat new in the computer industry, the concept has been around for a long time, and chances are that if you are a COBOL programmer, you already understand it.
When COBOL programmers first began developing mainframe-based applications that interacted with users (e.g. non-batch style applications), they were constrained to simple line-oriented ACCEPT/DISPLAY syntax.
Later, on-line transaction monitoring systems such as IBM’s CICS and IMS/DC enhanced this capability to handle full screen-oriented interaction (as opposed to line oriented). Some PC COBOL vendors later enhanced the COBOL ACCEPT/DISPLAY verbs in non-standard ways to provide full screen interaction.
While one could argue that none of these techniques qualified as event-driven programming, they were in fact, a primitive form of this approach.
Event-driven programming breaks the user interface portion of a GUI application (screen I/O, keyboard I/O, mouse I/O, and a few other possibilities), into a series of possible events.
These events include user actions such as pressing a key on the keyboard, moving the mouse, clicking the mouse on a screen object such as a button, holding the mouse button down and dragging the mouse to move a window, and so forth.
Writing a proper Windows GUI application entails creating all of the potential windows and objects that the user may interact with (including output objects as well), determining all of the possible events that may occur, and then creating a link between each potential event and your application code to handle the event.
What you aim to end up with is an application that registers its user interface with Windows (in much the same approach as CICS and IMS/DC applications register themselves in the mainframe world). Once the application is registered, Windows recognizes events and sends event driven messages to the application for resolution.
The registration and event handling processes are based upon the Windows message queue paradigm.
The Windows Message Queue
The Windows message queue is an exceptionally complex topic, and will be discussed only briefly to give you a basic understanding.
Much like CICS or IMS/DC (via VTAM) on a mainframe, Windows controls all input from the screen, mouse and keyboard. It must then implement a technique to manage all of this and ensure that any event that takes place is routed to the proper application. For applications that wish to update system I/O resources such as the screen, Windows also needs a mechanism to enable applications to alert it (Windows) to do so.
Windows provides these services by implementing a message queue. Every Windows application must register itself with Windows when it activates. As the user interacts with the system, messages are routed into each application as appropriate. Because Windows supports multiple applications running concurrently, this proves to be a very busy part of the operating system.
This means that any Windows application registers itself with Windows, and then goes into a recurring ‘message loop’ - simply reading in messages sent to it by the operating system and reacting as appropriate. This continues until the application receives whatever it has defined to be a ‘terminate application’ type of message and then it terminates itself.
It’s important to understand that an application can easily receive thousands of Windows event messages in a short period of time. For example, when a user moves the mouse around the screen, multiple messages are generated to alert the application whose window(s) the mouse passes over. These messages not only alert the application that the mouse has moved over the application’s window, but additionally provide information such as the exact location (x, y coordinates) where the mouse moved - even though the user did not press any of the mouse buttons!
If your application does not contain code to handle a certain message then it may lock up or be abended. Fortunately, a common programming technique is to provide a catchall routine that simply ignores all messages other than the ones you’ve defined.
Hopefully, you can begin to envision the Windows application environment where messages are being sent to applications as the user interacts with the system. The applications perform actions based upon the messages received and dispatch messages back to Windows to perform user interface operations (for example, close a window, create a new window, update the screen with the new data being passed along, etc.).
In a low level Windows application, developers are forced to write extensive amounts of code to deal with all of the possible events that may occur, manage the internal message loop, and take care of a great deal of tedious work. This work may even include being forced to re-paint the screen because another application’s window was placed on top of your application’s window. (Windows does not automatically keep track of the layering of application windows and will not automatically restore the prior contents of a window that was briefly overlaid.)
How PowerCOBOL and Visual Basic Simplify Application Development
One of the goals of Fujitsu’s PowerCOBOL and Microsoft’s Visual Basic is to effectively hide from the developer the tedious task of managing the Windows message queue and an application’s message loop.
Using PowerCOBOL or Visual Basic, a developer need only paint the application’s windows and contained objects (for example, buttons, list boxes, text fields, etc.). PowerCOBOL users may program these windows in intuitive COBOL code, while Visual Basic developers define (in a high level scripting language) how they are to interact with the user and the application. The developer then decides which potential events he or she cares about (for example, a button being pushed by a mouse click), and writes the code to handle each such event.
PowerCOBOL actually generates a great deal of the COBOL source code for GUI events and places it automatically into the COBOL program.
This approach frees the programmer from the tedious nature of low level Windows API message queue programming in order to concentrate on higher level aspects of the application.
Both PowerCOBOL and Visual Basic generate code for the application to handle any potential events that the developer forgets or simply does not care to define event code for.
Because some of this code can be quite tedious and complex (for example, re-sizing a window and re-positioning all of its objects), both PowerCOBOL and Visual Basic become great allies to the application developer who needs to field solid, fully functional GUI applications.
When developing these types of applications using Visual Basic, users must be very familiar with Visual Basic’s scripting language, which is very extensive and can be quite complex at times.
Additionally, developers sometimes run into development scenarios where Visual Basic may not provide a certain capability or provides it in a somewhat tedious manner versus another programming language such as ‘C’ or COBOL.
Lastly, developers often have legacy applications available that they would like to encompass in a GUI application. These legacy applications are often written in something other than Visual Basic script. This means that Visual Basic needs to be able to call programs written in languages other than its own scripting language. This is exactly where NetCOBOL comes into play.
By providing the capability to associate potential events in a Visual Basic controlled application to COBOL programs, the development environment is greatly extended. COBOL programmers can write sophisticated GUI applications with a minimal amount of knowledge of Visual Basic’s scripting language. They may additionally re-use existing COBOL code with little or no change within a Visual Basic application as well.
