Advanced PowerBuilder

Solutions to Common Debugging Problems

In general, there are times where the debugger won't solve the program's problems. This section is dedicated to those problems and some solutions we found. We hope that the following information may help you avoid these mines, and save you hours of struggling against unexpected PowerBuilder behavior.

In this section, we cover:

	Using the MessageBox() function in the debugging process.
	Problems with KeyDown() and GetObjectAtPointer() when debugging.
	Message Objects.

MessageBox()

Instead of using the step-by-step technique of debugging, you might decide to use the PowerBuilder MessageBox() function to indicate the passage of some code, together with pertinent information about the state of some variable or property.

In this case, problem arises only when the variable in display has a NULL value. In this case, PowerBuilder neglects to display the message box. In the debug window, you can see the MessageBox() being executed, but it never appears on the screen.

This often happens when dealing with embedded SQL commands. If the column you are selecting isn't protected by a NOT NULL flag or a default value, you run the risk of acquiring a NULL and falling fowl to this problem.

You can't perform a check with an equality sign, as shown below:

If Variable = NULL then ...

PowerBuilder supports an IsNull() function to check if the variable in question has a NULL value. You can also place NULL value checks in the embedded SQL:

SELECT "product_master"."product_description"
   INTO :lProductDesc:lDescInd1
   FROM "product_master"
   WHERE "product_master"."product_no" = :lProductNo ;

In the above example, you can check lDescInd1 for the presence of a NULL value in the lProductDesc variable. You will be learning more about embedded SQL in the coming session.

KeyDown(), GetObjectAtPointer()

When debugging, using the KeyDown() and GetObjectAtPointer() functions pose a problem. When debugging, the debug window is the active window and is placed in the front. During step-by-step execution, the key pressed is sent to the active window i.e., the debug rather than the active window in the application.

The solution to this problem is to set Stop Points above and below the line containing the KeyDown() function, and once the first Stop Point above the KeyDown() function is reached, select the Continue icon instead of the step icon. This allows the pressed key to be passed to the active window in the application, and the execution stops at the next Stop Point, i.e., after the KeyDown() function.

Do the same with GetObjectAtPointer().

Messages

To pass values between windows, you often use message object. Like KeyDown(), this works well at run-time. Typically while debugging, you go through the code step-by-step, watching the variables and trying to figure out what's happening. Unfortunately, by using this method of debugging, you are allowing time between execution of the lines, a result that itself produces adverse effects.

Windows is a message-based operating system. This means every application working under Windows sends and receives messages. When there is time left before you execute the line that checks the value of the message object, there is a chance that other application messages may override its content. This leaves the script without the required content of the message object.

At runtime, as there is no intervention in most cases, it works as you would want it to.

To overcome this problem, in the called event ( triggered event ) declare a local or instance variable and assign to it the message object value in the first statement of the event itself. For example:

// CommandButton cb_browse in WindowA
OpenWithParm( WindowB, "String Value" )

In the Open event of WindowB, you would then add the following line of code as the first line:

InstanceStringVariable = Message.StringParm