The PowerCOBOL Debugger has been carefully designed and integrated to provide optimal usage in an event-driven environment.
PowerCOBOL itself sits on top of a highly complex graphical user interface (GUI) based system.
In this GUI-based system, hundreds and possibly thousands of events may occur within a few seconds. These events may include something as specific as a user clicking on a close button or something as simple a user moving a mouse over a particular portion of an application window with no specific intent.
The Windows operating system manages each application process and the GUI display separately. When a GUI event takes place, Windows determines which application(s) are related and will compose and dispatch messages to this application(s).
For example, you may have noticed that many Windows applications (including PowerCOBOL's development environment) watch closely for a user to move the mouse pointer over an icon in the menu area. When the mouse pointer moves over any such icon, a small text box appears describing what function that icon will accomplish if selected (left clicked on).
In order for the actual application that comprises the PowerCOBOL development environment's user interface to provide this useful feature, it must first be told just when a user moves the mouse over a particular icon.
The Windows operating system accomplishes this task by recognizing when such an event takes place, composing a message saying so - including all needed details, and dispatching (sending) it into the appropriate application.
It is important to understand that the Windows operating system will compose and dispatch all event-related messages into an application - even if the application has no interest in a particular event or series of events. In some cases an application may ABEND (abnormally end) because it has not had an appropriate message handler defined.
Many development environments require the programmer to be aware of this fact and to write default message handlers for many types of events they do not really care about within an application. Some other language environments provide default message handlers in their run-time systems to handle this processing, but will pass messages through if it is determined the application really does care about a certain event.
PowerCOBOL falls into the later category.
Programs running under Windows may have many thousands of messages dispatched into them while they are active.
In many lower-level programming environments such as C and C++, the application itself must handle all messages. These applications are typically constructed to contain a message loop - a section in the program where each message is read from the message queue and interrogated to see if the application cares about it. If the particular message is of interest, then a specific function is called to deal with it. Once the function has completed its task, control is returned to the message loop and the next message is read and interrogated.
When using a Debugger in such an environment, you must be very careful to set breakpoints in appropriate places. If you have the misfortune of stepping into the actual message loop code, you may never get out, as the messages pile up very quickly, and you may generate numerous additional messages as a function of debugging the message loop. Because so many messages stack up so quickly, additional commands to the Debugger may not get through until the previous messages have been dealt with.
Another issue, when programming in a lower-level environment, is that during debugging you can easily step into source code that you did not write. There is a great deal of run-time support code and GUI abstraction code provided by any programming tool in a Windows GUI environment.
This code is typically linked into these applications from libraries provided with the development environment.
One of the features of PowerCOBOL that you will appreciate during debugging is the fact that as PowerCOBOL abstracts a great deal of the programming task, you never have to look at this run-time support code when debugging. You typically only debug code that you write.
This greatly simplifies the overall development process, and generally shortens the debugging task.
The PowerCOBOL Debugger is aided by the fact that the design of the PowerCOBOL system itself attempts to abstract much of this work from the application developer. Developers using PowerCOBOL only define event procedures for events they are concerned about within the application. The PowerCOBOL run-time environment takes care of the multitude of other Windows- composed event messages sent into a PowerCOBOL application.
This greatly simplifies both the application design and the debugging task.
It is important to realize, however, that a great deal of application processing is thus abstracted and is taking place transparently along with the processing you do see when debugging.
This may cause performance problems with the Debugger. It may, at times, appear slow when it is dealing with a large number of extraneous messages, or waiting for Windows to handle other processes.
When using the PowerCOBOL Debugger with larger and more complex applications (as is true with any Debugger in the Windows environment), you may at times want to pause slightly between mouse clicks or keyboard commands, or you might have such a request ignored (skipped). For example, you may actually lose a command because you get too far ahead of the message queue handling by the PowerCOBOL run-time system.
You may at times think the Debugger is locked up and not responding, when in fact the Debugger has returned control to your application and is simply waiting for an event to occur in the application, before returning control back to the Debugger.
Another potential problem comes from one of the very basic design decisions made in the Windows operating system.
An application may create (paint) a window on the screen that includes text and graphical objects (for example, menus and push buttons).
Because Windows is a multiprocessing operating system, thus allowing multiple applications to run concurrently using the same display, your application's window may be overlapped by another application's window being painted on the screen.
Windows does not always keep track of its processes, however; it will not necessarily "refresh" the screen automatically to show your application's current window.
In general, the Windows operating system does not keep track of everything inside of application windows. This means that if another application window overlaps your application's window on the screen, portions of your application's window that were overlapped will effectively be overwritten and lost on the display.
The effect you might see when the other application is exited and your application's window is again made visible is that all or part of your application's window will contain parts of whatever was just displayed over top of it.
Windows does not keep track of the contents of application windows because of the overhead associated with doing so. Instead, Windows will compose and dispatch a message alerting an application that one of its windows has been overlaid in such a manner, thus requesting a repaint process from the application itself. The application then repaints its window.
This is another excellent feature in the design of PowerCOBOL; it takes care of managing this situation for you and you need not worry about creating processes to repaint your application windows when this occurs.
However, it is important to understand this design feature of Windows when you are debugging in the PowerCOBOL environment. The reason behind this is that control passes between your application's GUI interface and the PowerCOBOL Debugger as you debug your application.
As previously noted, the PowerCOBOL Debugger may appear to be frozen and not responding to your requests, when in fact it has returned control to your application's GUI interface and is awaiting user interaction to generate an application event.
Likewise, at times you may see your application's window overlaid with another application's window and not refreshed. It may appear at first as if your application has some serious problem or error in it. The explanation behind this is that control may have passed from your application's GUI interface back to the Debugger. While the Debugger is in control, your application's window will remain unchanged until an event is raised within the Debugger to cause an update to the application's window. The window will then be repainted and should return to its normal look and feel.
Overall, it's important to remember that the PowerCOBOL Debugger is attempting to insert itself between the very active event-driven message architecture of the Windows operating system and your actual application. At the same time, it is trying to co-exist with and run under the auspices of the PowerCOBOL run-time system which is itself attempting to abstract a large portion of the tedious application processing from your application.
It is thus very important to understand how to best use the Debugger within your application development process. If you keep a keen emphasis on the most logical places to set breakpoints and allow the Debugger to run quickly through large parts of your application code that you are comfortable with, you will optimize your overall productivity.
