|
Power Objects provides a full-featured, run-time debugging environment. With the debugger, a developer can set breakpoints, watch variables, set the value of variables, and step over, around, and through code. This chapter explains how to use and take
advantage of the Power Objects debugger.
Power Objects provides a run-time debugger so that developers can debug their applications. Syntax-related bugs are not the type of bug that a developer generally needs to track down; a syntax-related bug is caught during compilation. The typical bug is
a programmer-generated logic bug. In order to pursue a bug, the developer must have a method for activating the debugger. There are three methods for initiating or activating the debugger.
Two of these methods are controlled through the design-time menu. The menu commands include Use Debugger and Debug Startup Code. The Use Debugger menu command activates the debugger palette when you're running an application, form, or report during
design time. The Debug Startup Code menu command also activates the debugger palette when you're running the application, form, or report; and, it also stops execution at the first Basic statement of the first startup method containing Basic code. If none
of the startup methods contain Basic code, execution will not be stopped. The third method is to use the STOP command. This method is documented but does not actually work in Oracle Power Objects Version 1.0. If you use the STOP command and run the
application, once the run-time environment encounters the STOP command, it generates a Basic error, BAS-00322: General syntax error. This error is followed by BAS-01058: Error compiling source code.
When using the run-time debugger, the first component of the debugger that the developer encounters is the debugger palette. Figure 43.1 illustrates the four components of the debugger palette. The first component is the Continue button, which tells the
debugger to resume execution of the application. The second component stops or halts execution of the application. The third component opens the debugger's main window, and the fourth component opens the debugger's expressions window.
Figure 43.1. Debugger palette.
Oracle designed Power Objects applications to respond to user input. The types of input include keyboard and mouse events. The startup condition for a Power Objects application is not affected by these types of input. Executing the startup code permits
the application to achieve a steady state in which it can then begin to process the various user inputs. If a developer wants to debug the startup code, he must check the Debug Startup Code menu option. Otherwise, the debugger activates the debugger
palette immediately after the startup code has been processed.
The Debug Startup Code menu option and the debugger palette's Open Debugger icon both enable you to activate the debugger palette and open the debugger main window. Figure 43.2 shows the debugger main window open for debugging the startup code for the
Finance sample application.
Figure 43.2. Debugger window.
Experienced Power Objects developers will notice that the run-time debugger windows are not limited to the boundaries of the Oracle Power Objects design environment window. The debugger palette, debugger main window, and debugger expressions window are
non-MDI (multiple document interface) windows, which permits their boundaries to be independent of the design environment.
Usually, developers have a general idea of where to begin looking for a bug. They attempt to narrow down the problem area by using break points and watching the values of variables throughout the entire application. The debugger main window enables the
developer to set and clear break points within the application. To illustrate setting and clearing break points and other debugging operations, I use the Finance application. The amortization screen has a button that updates the amortization schedule. I
want to set and later clear break points within the recalculation code. Figure 43.3 displays the Click() method code for the btnAmortize button.
Figure 43.3. Setting a break point.
The stop sign symbol to the left of the FOR i = 1 to vNumPayments line indicates that I set a break point. An open hyphen symbol to the left of a Basic statement indicates that you could set a break point for that line, but one has not yet been set. If
there is no symbol to the left of a Basic statement, the statement cannot have a break point set. What I have done is set a break point at the beginning of the For loop and immediately after the completion of the For loop. The purpose is to determine if
the loop is executing the proper number of cycles and also if the remaining balance is calculated correctly.
If the developer is through debugging a specific bug and wants to clear all break points, he can click the Debugger Window icon, which contains a pencil erasing a bug. You can clear a single break point simply by clicking the stop sign symbol; the break
point is effectively a toggle condition.
Querying the value of variables and other application objects during run time is what enables the developer to determine where a bug exists. The debugger has a separate debugger expressions window that permits the developer to specify variables to
query. Figure 43.4 illustrates the debugger expressions window with a number of variables and expressions to watch.
Figure 43.4. Watching an expression value.
Many of these variables and expressions are selected to be updated at every break point or stoppage of execution within the debugging environment. Expressions are updated automatically if they have the yellow triangle to their left, but you can update
them manually by selecting the expression with the mouse and pressing the Enter key. By clicking the Resume icon in the debugger main window, you can watch the expression values change on every cycle through the For loop. The Resume icon proceeds with
execution until the next break point is encountered or until the application stops execution under programmatic control.
The run-time debugger not only provides the capability to set and clear break points and watch the value of expressions, but it also provides the capability to step into, through, and over code. When the debugger is running through the code in a method,
it shows the next line to be executed in a reverse video highlight. Stepping into the code implies that if the next statement to be executed is a method attached to an object, the debugger will trace the statement to that object method and continue
debugging from there. If the statement is a Basic function, stepping into it is the same as executing the statement and staying in the current object method code. Stepping through a statement results in executing the statement without the debugger tracing
into it. The debugger stops on the next executable statement. Stepping over a statement executes all the remaining statements in the current method without the debugger tracing into them.
There are two other nice features of the debugger. The first is documented. The Call Chain icon displays the object hierarchy that lead to the current method being executed. For example, if a button Click() method calls a form InsertRow() method, then
when the debugger is in the InsertRow() method, the call chain indicates that the button Click() method called the InsertRow() method. The developer can immediately jump to the Click() or InsertRow() method to interrogate values or to set break points.
The final nice feature of the run-time debugger is not documented very well, but it's one of the more valuable options. You can change the execution point during run time. All the developer needs to do is click the statement that is displayed in reverse
video highlight and move the highlight to the new starting point. The only limitation is that the next starting point must be further down in the code. You cannot back up the execution point. Moving the execution point helps you avoid problematic code.
The Oracle Power Objects run-time debugger provides an object hierarchy diagram in the debugger window. The debugger window also displays methods that have code in them and the values of properties of the currently selected object. The debugger displays
values of expressions in the debugger expressions window. A developer can accomplish a lot with these capabilities, but the debugger still has several shortcomings.
One of the shortcomings is that you cannot debug a class object. This applies only to the master class method code. If an instance overrides the master class method code, then you can debug the overridden code.
Another limitation is that working with modal dialog boxes causes the debugger to hang up the Microsoft Windows environment. The only method of escape is to reboot the entire machine. A final limitation of note is that looping constructs such as the For
loop only seem to receive the execution focus once. In order to debug a For loop on every cycle, you must set a break point on the first statement after the For loop initialization statement. This is really only a nuisance because it is not critical to the
overall performance of the debugger.
Oracle Power Objects has delivered a functional run-time debugger. The debugger provides the minimum set of features necessary to successfully debug an application. The object hierarchy browser provides a diagrammatic view of the application. The
expressions window is reliable and updates in a fashion that does not impede run-time execution performance. The capability to move the starting execution point is very nice, and the online documentation should have discussed it more prominently. Although
there are some limitations to the run-time debugger, the overall performance and capabilities of the debugger make it very useful in tracking down developer-generated logic bugs.
| 
