Event Procedures and Diagnostics

In general terms, the underlying GUI communicates with the program via events. When an event is passed to a program, the expectation is that the program handles the event in a generally reasonable amount of time and then returns the user to the GUI. In the majority of cases, the GUI is unresponsive until the event handling completes.

An event procedure is an integral ingredient of a sophisticated graphical user interface because it essentially enables you to code multiple events into a single UI event, such as the click of a button. Unlike in single event processing, an event procedure can return control to the GUI before all processing is complete, depending on the structure of the procedure.

You can code an event procedure to process more than one system message. Each system message can generate one or more of its own events, resulting in event-handler nesting. In ACUCOBOL-GT, this most commonly occurs when an event procedure for one ACCEPT statement executes another ACCEPT statement for the GUI, causing one ACCEPT to nest inside another. This is an acceptable practice to a point, but be aware that event procedures can become complex and thus provide the perfect environment for introducing bad coding practices.

For example, while technically possible, it would be bad coding practice to provide a single button in your GUI that starts your payroll system and runs the entire system as part of a single event procedure! Another scenario to avoid is to have a program attempt to finish a parent event procedure before the child events are finished. While the ACUCOBOL-GT specific threading mechanisms along with COBOL flow-of-control features enable the COBOL runtime to handle this scenario properly, Windows does not, often resulting in stack corruption.

In addition, we recommend that you avoid nesting the processing of multiple screens using a single ACCEPT statement, especially when multiple threads are also involved.

Inevitably, when bad code causes a problem during the execution of an event procedure, pinpointing the cause can be a challenge, especially when the problem is a failure of an event procedure to finish processing in a timely manner, or to finish processing at all. If you have an event procedure that runs for several minutes, it might not be doing what you think it is doing! To help you diagnose problems with event procedures, ACUCOBOL-GT allows you to set a time threshold on the execution of an event procedure, after which the procedure is flagged and a report generated.

Note: This topic applies to Event Procedures only. Before/After/Exception Procedures are not technically nested; they occur either before or after the corresponding ACCEPT executes, which is why using exception values for push buttons is preferred.

The following topics provide information about preparing for, executing, and reviewing output generated by event procedure diagnostics: