SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, 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.

The Southern California OS/2 User Group
USA

January 2002


 Dear Mr. Know-It-All 

Mr. Know-It-All has the answers to even the really tough questions.


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()
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 Mr. Know-It-All
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 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.