One of the benefits of PowerCOBOL is its support for traditional COBOL syntax. There is some complexity involved, however, when traditional COBOL (COBOL 97) and PowerCOBOL procedures are intermingled. This section describes some of the issues you need to be aware of, and provides examples of each.
Recursive calls are not permitted in COBOL.
Windows supports recursion. In other words, Windows allows programs to call and be called by each other. However, the COBOL standard does not support the recursive call of procedures. To avoid errors when using recursive procedures in PowerCOBOL, limit them to event procedures. Do not attempt to call COBOL procedures recursively from a PowerCOBOL event procedure.
The PowerCOBOL execution environment shuts down when you call a COBOL procedure from within a PowerCOBOL procedure.
If you open a PowerCOBOL form from within a COBOL program, a new PowerCOBOL execution environment is built. And if this COBOL program is called from within another PowerCOBOL event procedure, two execution environments are built.
Follow these two rules when using PowerCOBOL:
Each form name must be unique within an application.
Do not open the same form twice within an application.
NOTE: These rules do not extend across execution environments. For example, you cannot open a SUBFORM in a new execution environment if the SUBFORM has already been opened in the original execution environment. If you try to open the same form in the same execution environment within the same application, the run-time system returns an error code. The run-time system does not catch this error if the execution environments differ. For example, you can open SUBFORM from DLLFORM, but the new SUBFORM will destroy the area in which the old SUBFORM was stored.
A form will not close until all of the processing event procedures are completed.
NOTE: Even if the Deactivate method is issued, a form will not close until all of the event procedures in process come to completion.
Events process asynchronously. Generally there is little or no delay between the time that the Deactivate method is issued, and the actual closing of the form. Sometimes, if a long event procedure is processing when the Deactivate method is issued and control is returned to the Windows operating system, the form will be open until the procedure comes to completion.
Although a sequence of events takes place when you click on the Open button in the MAIN form, ultimately, the DLLFORM is opened. So, when you click on the Close button all of the procedures along the way, including the DLLFORM, must close before the MAIN form can close.
NOTE: The POWEROPENFORM method will not relinquish control of the application until every sub-procedure closes.
