Question:

I've just started to use DrDialog. The GUI building and REXX coding is pretty easy, but I'm having lots of trouble using the Run-Time window to debug programs. I've RTFM and I still can't seem to get the trace modes to work the way the manual describes them. Can you help?

Answer:

Yes, I can. Your problems are a combination of somewhat unclear documentation and some defects in the implementation of the Run-Time window.

The first thing to understand about DrDialog's Run-Time window is that once you click the Run button, your program is always running until you click the Stop button, no matter what you do with the other buttons or fields. At any point in time, your application is either running REXX code to process an event or waiting for the next event. If your application is waiting for an event, DrDialog will allow you to execute commands entered from the Interpret entry field. However, your application is still running and ready to process events. To see this, just click on one of your application buttons.

Clicking on the Break button, does not stop your application. What it does is terminate the current event handler. Your application then waits for the next event. If there is no event handler running, clicking on the Break button does nothing. The manual does not state this clearly, but the only real use of the Break button is to stop event handlers that are stuck in a loop. If you use the Break button to stop an event handler, some of the code in your handler did not execute. Depending on what did not execute, you may need to restart your application to continue testing.

Interactive debug mode is very powerful once you understand how it fits into the DrDialog execution model. Once interactive trace is active, you can single step though your code, display variables or set variable values. However, Interactive trace does not change how the event model works. If your application is waiting for an event, events will be detected and the handlers will be invoked.

You can only change the trace mode when your application is waiting for an event or after interactive trace mode is active.

If the application is waiting for an event, changes to the trace settings do not take effect until the next event triggers. This can make it appear that your settings changes did not take.

The manual is misleading when it says the Trace button does not turn the trace mode on and off. Most of us think of the interactive trace state as part of the overall trace mode.

To start interactive tracing, wait for your application to go idle waiting for the next event. Unless you have long running events, your application will be idle whenever the Evaluate button is displayed. If you are not sure, click on the Break button. If nothing happens, your application is idle. If an event handler was running, you will see the HALT message. Remember only the current event handler was terminated, your application is still running. Now, use the drop down list to set the trace mode and use the Trace button to toggle interactive debug on, if you wish. Depending on the trace mode you selected, it may appear that nothing has happened, but it has. The selected trace settings will take effect when the next event triggers. To see this, trigger an event in your application. Depending on the trace mode you selected, clicking on the Evaluate button may generate trace output and cause the Bug button to appear.

If you enabled interactive debug mode, the Bug button will appear. Click on the button to single step your application. When the event handler exits, the Bug button will change to the Evaluate button. The trace mode has not changed. The Bug button will reappear when the next event triggers.

Turning off interactive debug mode is where it gets interesting. Changing the trace mode with the listbox works as expected. However, DrDialog does not always do the right thing when you click on the Trace button. In fact, it rarely does the right thing. When this appears to be the case, enter:

  say trace()

  call trace ?

If you need to debug startup code, DrDialog makes this somewhat difficult since the Trace button and the listbox are disabled until you start your application. You will have to insert the statements:

  call trace ?a; say trace()

Once you get used to the workarounds for DrDialog's trace control defects with the Interpret entry field, you will find debugging DrDialog code much more pleasant and productive.

Given the overall quality of DrDialog, Mr. KIA can only suspect that the trace defects did not always exist and that some change in the REXX interpreter caused the problems to appear.

Copyright 2002 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.