FREE PowerBuilder Training

Advanced PowerBuilder

HomePrevious Lesson: Running Your Application
Next Lesson: Solutions to Common Debugging Problems

Stop Points

There are two ways to run a program in Debug mode: Stepping and Continuous. Stepping allows you to move from one command to the next command, pausing until it is forced to move onto the next entry. This can be time-consuming and may not provide information about the part of the program we are interested in. The other method, Continuous, allows you to run  command after command; a task the computer continues to perform until it reaches the end of the listing, or until it encounters a Stop Point.

A Stop Point is a flag that can be set against any line of the program, which PowerBuilder recognizes as a request to temporarily halt the program, until asked to move on. This allows you to quickly move to the trouble spot. At this point, you can change to Stepping, in an attempt to slowly work through each line of code to further narrow down the location of the problem.

Using Stop Points

When you open a debug session, PowerBuilder might show the Edit Stops dialog box. This dialog box displays the Stop Points for the current application, set in the previous debug session.


This dialog box displays the Stop Points set for the code associated with this application, and not just for the requested slice of code.

When you are ready to run the debug session, select Start, and as soon as PowerBuilder encounters the first Stop Point, it displays the main debug window. The Stop Point, and the 'code of interest' appear in the Code section, while the watch displays the current values of the variables and properties of interest - you are debugging!

Flow in the Debug Window

There are several options in the Debug PainterBar, which allow you to control the flow of execution and the things that should be visible in the Debug window:

If you want to see the execution of the script, line-by-line, click on the Step icon. PowerBuilder moves through the script, one line at a time, taking no notice of the set Stop Points. You might decide when to jump to the first Stop Point.

If you hit the Continue icon, PowerBuilder runs the application normally. The only way to tell if you are in the Debug mode is to run script, that has a Stop Point associated with one of its lines. You are automatically thrown into the debug window when PowerBuilder hits that Stop Point.
Note that the Continue icon replaces the Start icon on the PainterBar, when PowerBuilder runs in the Debug mode.

Suppose you wrote script for the clicked event of a CommandButton to call a function and trigger certain events. If you set a stop for the CommandButton's clicked event, you can see the execution of the function and the triggered event step-by-step, in the debug window. In turn if this function calls a second function, it's also displayed in the debug window.
If there is a PostEvent() function in the script you are debugging, the event called through the PostEvent function won't be displayed in the debug window, unless a Stop Point is set in the Posted event.

Before we look into the techniques and problems that can be encountered while debugging, let's ready the scene setting, so that the debugger can do its stuff.

Adding Stop Points

When you first approach a code with the intent of using the debugger against it, you need to set up some Stop Points. If there aren't any selected Stop Points in the application, PowerBuilder throws you straight into the main debug window.

You can place Stop Points against any line of code simply by double clicking against the line number.
Actually, Stop Points can't be associated to every line in the code. They include commented lines, variable definitions and blank entries. In fact, Stop Points can be set against lines which actually alter something, as opposed to improving the readability or some preparatory work for the code to run successfully.

You can repeat this task as many times as you like, denoting each and every key point in the program as a point where you would like to stop and review the progress.

Stop Points and Embedded SQL

Embedded SQL has its own restrictions. For the purpose of Stop Points, PowerBuilder reads all declaration statements as no-go areas. It means that a SQL declaration statement, which might include cursor and procedure declarations is read the same way an integer declaration is read- no Stop Points allowed. PowerBuilder also has problems with embedded SQL statements that span multiple lines. Clearly, due to the way the SQL is structured, it doesn't make sense to stop a program half-way through the SQL statement. You either need to read the SQL statement or none at all, and so PowerBuilder won't allow you to place a Stop Point between the first and the last lines of a multi-line embedded SQL statement.If you want to set such an SQL statement as a Stop Point, double click on the last line. For example, to set a Stop Point on the following SQL statement, you would double click on the line that contains the FROM clause, the line that has the SQL statement terminator:

SELECT "product_master"."product_no",
   INTO : lProductNo, :lBalance
   FROM "Product_master" ;

Editing Stop Points

After you set the Stop Points you require in the code, you might like to try out the Edit Stops dialog box:

If you try to open the debug session on some code that already has some Stop Points associated with it, this dialog provides you with the ability to review and modify any or all of those Stop Points.

Enabling and Disabling

While debugging a program, as you try to narrow down the problem, you may set several Stop Points. If you try to run the debug session with all these Stop Points in place, you might find it time-consuming to get to the 'interesting' part of the program.

To circumvent this problem, PowerBuilder allows you to temporarily disable the earlier Stop Points, removing the need to pass through them. The debugger doesn't pick up on any disabled Stop Points, only the enabled ones.

PowerBuilder displays the status of each Stop Point in two different ways:
The Stop Point symbol is grayed out for a disabled entry.
The entry in the Edit Stop dialog is altered to reflect the new status of the Stop Point.

No matter how you  review the status of the Stop Points, PowerBuilder allows you to affect the status only through the Edit Stops dialog box.

This dialog box also allows you to add and remove Stop Points, whilst providing information about each in turn.

Changing Variable Values

While debugging a program that contains many changing variables, you may want to modify them. For example, in a loop you may want to increase the value of the counter in order to jump forward in the program; or if you have a menu selection window which gets input from the user, you may want to change the input value to test all the options, without running the full program every time.

You can see that this displays the variable name and its current value. You can enter a new value or set the value to Null.

Adding Watches

As we have already seen, PowerBuilder allows you to set watches against key variables, enabling you to track those values without the baggage of a variables scope, or the organizational structure of the variables hampering your efforts.

By indicating the exact variable(s) you wish to concentrate, PowerBuilder is capable of setting the appropriate watch, illustrating a unique 'path' to the variable/property and providing the current value of that item at any time before, during and after the debugging process is complete.

To add a variable to the watch window, simply highlight the variable in the list and click on the Add icon, in the PainterBar.

Debugging Inherited Objects

When debugging inherited objects, script written for the ancestor objects will not be displayed in the debug window. If you want to see the ancestor script while debugging, you need to set a break point in the ancestor script.

If there are several levels of ancestors and if you set break point at the top level, you will be able to see all the descendant scripts executing in the debug window.
HomePrevious Lesson: Running Your Application
Next Lesson: Solutions to Common Debugging Problems

Copyright © 1996 - 2013 Prasad Bodepudi. All Rights Reserved.