Mr. Know-It-All has the answers to even the really tough questions.
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?
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
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:
in the Interpret entry field. If, as suspected, the output indicates
interactive trace is still on, enter:
call trace ?
to turn it off. You must use the function call form. DrDialog will not
allow you to use the trace command form. If the Bug button is displayed,
click on it to get trace mode and the display into the same state. The
Evaluate button will appear.
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()
at a convenient place in your startup code. This will enable tracing and
display the settings in the output window. The Trace button and listbox will
be out of sync with reality. If this bothers you, you can correct this as
described above, or you can just ignore it. Of course, you can replace ?a
with any setting you need.
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.
Curious or in doubt, you can ask
OS/2 is his specialty and sharing solutions is his passion
Mr. Know-It-All lives in Southern California.
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2002 the Southern California OS/2 User Group. ALL RIGHTS
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.