Tivoli Service Desk 6.0 Developer's Toolkit Tools and Utilities Guide
The Developer's Toolkit Debugger is used to debug Developer's Toolkit programs. Using the Developer's Toolkit Debugger, you can review the step-by-step execution of run-time code.
The following sections describe the basic techniques for working with the Developer's Toolkit Debugger. Additional information about working with different viewers is contained in subsequent sections.
There are several ways you can start the Developer's Toolkit Debugger. The Developer's Toolkit Debugger starts in single-step mode; that is, code execution stops. You can then use step in, step over, or step out to debug the code. For more information, see the section Tracing Execution Paths in Code later in this section.
KML -t <.kbc file name>
Note: <.kbc file name> must be in compiled or parsed format to run.
If you choose to open the Developer's Toolkit Debugger, the line that was executing when the error occurred is selected. If the debug510.dll is not present, any error messages you receive do not contain the option to start the Developer's Toolkit Debugger.
Note:
The Run menu contains two commands that can be used to quit the Developer's Toolkit Debugger: Close and Abort.
The Developer's Toolkit Debugger enables you to debug without having the actual source code present. (What you see in the Developer's Toolkit Debugger is not an exact copy of the source code.) The process of reorganizing source code results in the following changes:
Source | Developer's Toolkit Debugger |
x :=3*(5+4); | x := 27; |
Source | Developer's Toolkit Debugger |
x :=c *(a+b); | x :=c*a+b; |
Source | Developer's Toolkit Debugger |
3 June 1997 | 6, 3, 1997 |
The Developer's Toolkit Debugger has a code viewer that displays all the modules in a .kb file. These include:
The Lexical tab, located to the right of the code viewer, provides a high-level view of an application's structure. It contains a tree of the modules in your program as well as the corresponding functions in each module.
To select a function to view:
Note: The Developer's Toolkit Debugger automatically displays functions when it encounters a break point. For more information on break points, see the section Break Points later in this chapter.
Variable viewers are used to see the storage data and access paths for local and global variables.
You can view a variable in the following ways:
A variable viewer shows information for all fields in a record. If any field changes its value, the entire variable viewer refreshes.
Note: If the record being accessed by the variable viewer is large, it may take a few moments for the variable viewer to refresh itself.
To set a variable for automatic refresh:
Note: A variable viewer may be left open in the Developer's Toolkit Debugger as you work with an application.
The variable window can only be closed manually, by choosing the system menu or by choosing Close, in the Variable Viewer dialog box.
The stack is located below the code viewer. Clicking a function in the stack makes the function appear in the code viewer, with the current line highlighted.
Note: Developer's Toolkit functions are recursive, meaning that you can step into a function multiple times in the same Developer's Toolkit Debugger session. The name of the function appears in the stack viewer for each recursion.
When you step out of a function, its name disappears from the stack.
Using the Developer's Toolkit Debugger, you can trace the execution path of an application. To do this, the Developer's Toolkit Debugger provides three options:
Stepping in executes the next line of code and, if a function call exists, steps into the function. Stepping over executes the next line of code without stepping into function calls. Stepping out executes the code until the end of the current function.
You can step in, out, or over code by choosing commands from the Run menu, or by clicking the corresponding buttons on the Developer's Toolkit Debugger toolbar. In addition, keyboard shortcuts are provided:
As you work with the Developer's Toolkit Debugger, you work through various levels of function calls. Each function can have embedded function calls.
The Developer's Toolkit Debugger enables you to step into the functions in your code and view the actions defined in the function. As you step into code, remember these points:
You can do any of the following to step into code:
You can continue stepping through a function to advance to the next action defined in the function. Eventually, you reach an END statement. At that point, pressing CTRL + I again returns you to the point in the calling function where you stepped into the code.
When you step out of a function, the current function, procedure, or event handler is executed without tracing; you do not see the line-by-line execution of the code. Tracing resumes on the first statement after the call.
Note: If you step out of an event handler, tracing resumes at the statement that generated the event. If more than one event was generated, tracing resumes at the beginning of the next event.
You can step out of code whenever execution is stopped in the body of a function or event handler. You can also step out of code if execution has stopped at a break point.
You can do any of the following to step out of code:
In addition to stepping in and out of code, you can step over code. Stepping over code traces the execution path at the statement level. Execution continues until the next statement is reached.
Note: Execution stops if there are errors or break points in the function that was stepped over.
You can do any of the following to step over code:
Break points are a method of stopping the execution of run-time code for purposes of checking on the current status of the execution. When a break point is encountered during execution, the Developer's Toolkit Debugger displays the function with the line containing the break point selected.
Note: Do not set break points in an event handler while it is processing $MsgDDEInitiate. $MsgDDEInitiate broadcasts a message to the applications and locks the message queue until a response is returned. Triggering a break point initiates an event handler that waits for a response from the (locked) message queue. This results in a deadlock, which effectively locks the user interface.
Temporary break points exist only while a Developer's Toolkit program executes. Temporary break points automatically clear when you quit the Developer's Toolkit Debugger session. You set these break points as you interact with function viewers.
To set a temporary break point:
Note: Temporary break points must be set on statements that can be executed. You cannot set break points on lines beginning with ELSE and ELSEWHEN statements.
You can place static break points in Developer's Toolkit program source code by using the BreakPoint statement. A BreakPoint statement can be added wherever there is a "point of interest," such as the start of a function call or event. This enables you to halt the application at a logical stopping point and review the current state of the application. The only way to remove a BreakPoint statement is to delete it from the source code and reparse the application.
You can create a menu command to associate with the BreakPoint statement. This enables you to start the Developer's Toolkit Debugger from the application.
The Developer's Toolkit Debugger does not run if the debug510.dll is not present.
You can debug windows and dialog boxes by setting a break point on WinCreate or DlgCreate. These statements identify event handlers that process window events.
To trace the execution of WinCreate, step into WinCreate, and then step out of each message generated.
Note: Do not use the Developer's Toolkit Debugger to trace paint, activate, or mouse processing.
Tivoli Service Desk 6.0 Developer's Toolkit Tools and Utilities Guide
-->