Progress
Debugger Guide
Starting in Application Mode
This technique is useful both for debugging complex code paths in the invoking application and for running the Debugger as a tool from one procedure to debug other procedures. It is especially helpful in large applications under development where the line numbers change constantly and you want to follow the code paths in a consistent manner—especially in an event-driven application with a large number of triggers. When implementing a Debugger tool in application mode, you can also specify a subprocedure for the Debugger to use as its initial executing procedure.
Debugging the Invoking Procedure
To start the Debugger from the 4GL so that the invoking procedure becomes the initial executing procedure, follow these steps:
- Add a DEFINE VARIABLE statement that defines a logical variable you can use to assign the return value for the DEBUGGER handle.
- Add a DEBUGGER handle statement that invokes the INITIATE( ) method before the point where you want to begin debugging the invoking procedure. This initializes the Debugger, but does not immediately start it.
- Add a DEBUGGER handle statement that invokes the SET-BREAK( ) method to set at least one breakpoint that occurs after the statement where you set it. The SET-BREAK( ) method that sets the breakpoint must also execute after the statement that invokes the INITIATE( ) method in Step 2.
- Run the invoking procedure.
For example, in the following listing fragment, the Debugger is initialized on line 5, and the procedure stops at a breakpoint on line 13. The Debugger takes control at this point. From here, you can continue executing the invoking procedure under Debugger control, stopping at and continuing from all breakpoints:
NOTE: In this example, the DEBUGGER handle statements share a line with existing code (line 5 is originally blank). This preserves known application line numbers for other breakpoints you plan to set after the debugging session begins.When you exit the Debugger, it returns to the invoking procedure, which continues execution from its current stopping (or breaking) point as if the Debugger were never initialized. If you exit the procedure before exiting the Debugger, the Debugger continues running until you either exit the procedure startup environment or explicitly exit the Debugger. When the invoking procedure exits, it returns to its startup environment.
Debugging a Specified Subprocedure
To use the same technique to debug a subprocedure called from the invoking procedure, follow these steps:
- Add a DEFINE VARIABLE statement that defines a logical variable you can use to assign the return value for the DEBUGGER.
- Add a DEBUGGER handle statement that invokes the INITIATE( ) method before the point where you want to begin debugging the called subprocedure. This initializes the Debugger, but does not immediately start it.
- Add a DEBUGGER handle statement that invokes the SET-BREAK( ) method to set a breakpoint at the first executable line of the subprocedure you want to debug. This statement must execute after the statement that invokes the INITIATE( ) method in Step 2, but before the statement that calls the subprocedure.
- Run the invoking procedure.
The following listing fragment prompts the user to enter the name (
procname
) of a procedure to debug (line 30). It then initializes the Debugger (line 33) and sets a breakpoint on the first executable line ofprocname
(line 34). When the invoking procedure callsprocname
(line 35),procname
breaks immediately on its first executable line and gives control to the Debugger. The Debugger then displays the listing forprocname
in the Debugger window as the current procedure:
NOTE: Using this technique, the invoking procedure executes in the Debugger context. Thus, if you enter a SHOW STACK command, the invoking procedure appears on the call stack. You can set breakpoints in the invoking procedure and break into it with the Debugger. In this type of application, you might not want the invoking procedure running in the Debugger context like this. You can prevent the invoking procedure from entering the Debugger context by prepending its procedure name with an underscore ( _ ). In this case, the Debugger ignores the invoking procedure completely, and it never appears on the call stack.Although this is a simple example, it illustrates the basic elements required to build a Progress development tool that can start debugging sessions for specified application procedures.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |