3rd-party PB Tools (episode 2)

This is the second post in the “Tools that all PB developers should be familiar with” thread. We’re going to stick with PBLPeeper for now, but we’ll be looking at a the PBDEBUG file viewer. This is quite possibly, the coolest feature I’ve ever seen, and one I’m sure you’ll use again and again. Before I begin, let’s review PB application debugging techniques in general.

I’m sure every PowerBuilder developer is familiar with the integrated Debugger. It allows you to step through the code of an application or component, and see exactly what’s happening at runtime. You can inspect and change variable contents to see how your program reacts, you can change the flow of the program and step over or around troublesome code… An integrated step debugger is a critical feature of any programming IDE, and while PowerBuilder’s has taken a beating in public opinion over the years, it’s still the #1 debugging tool we’ve got.

There’s another debugging technique that probably has slipped under the radar for most of you – I’m referring to the /PBDEBUG switch and the resulting .DBG file output. The .DBG file is a line-by-line trace of literally, every line of PowerScript that is executed while running an application.

There are two methods for creating a .DBG file.

1.  When running your application from within the IDE:

PB System Options dialog

In the System Options dialog of the IDE, turn ON the checkbox labelled “Enable PBDebug Tracing”. Specify a path/filename in the “PBDebug output path” field, and check whether you want the .DBG file automatically overwritten or not. As long as these options are set, you’ll get a .DBG file for your application whenever you execute it from within the IDE. It’s important to note that this option slows down execution of your app dramatically, so you do NOT want these on all the time. Typically, I set these options ON, run my app to get the .DBG file, then immediately turn them OFF.

2.  When running your application as a compiled executable

There may be a point where you need your users to create this file for you, and they won’t have the PB IDE installed. Simply create a shortcut for your app’s .EXE file, and add the switch /PBDEBUG to the commandline. This will create the file in the same folder as the .EXE, and it will be named yourApp.dbg.

With either approach, you now have a (probably HUGE) text file containing a line-by-line trace of all the code that got executed during the test. The lines shown below are an excerpt from a typical .DBG file.


Executing event +OPEN for class PFC_W_SPLASH, lib entry PFC_W_SPLASH
  Executing instruction at line 1
  Executing object function +OPEN for class W_POPUP, lib entry W_POPUP
    Executing instruction at line 43
    Executing object function +PFC_PREOPEN for class W_SPLASH, lib entry W_SPLASH
      Executing instruction at line 1
      Executing object function +PFC_PREOPEN for class PFC_W_SPLASH, lib entry PFC_W_SPLASH
      End object function +PFC_PREOPEN for class PFC_W_SPLASH, lib entry PFC_W_SPLASH
      Executing object function OF_SETBASE for class W_SPLASH, lib entry W_SPLASH
        Executing instruction at line 52
        Executing instruction at line 56
        Executing instruction at line 57
        Executing instruction at line 58
        Executing object function +CREATE for class N_CST_WINSRV, lib entry N_CST_WINSRV
          Executing instruction at line 2
          Executing object function TRIGGEREVENT for class N_CST_WINSRV, lib entry N_CST_WINSRV
            Executing system dll function
          End class function TRIGGEREVENT for class N_CST_WINSRV, lib entry N_CST_WINSRV
          Executing instruction at line 3
        End class function +CREATE for class N_CST_WINSRV, lib entry N_CST_WINSRV
        Executing instruction at line 58
        Executing instruction at line 59
        Executing object function OF_SETREQUESTOR for class N_CST_WINSRV, lib entry N_CST_WINSRV
          Executing instruction at line 46
          Executing instruction at line 50
          Executing instruction at line 51
          Executing instruction at line 52
        End class function OF_SETREQUESTOR for class N_CST_WINSRV, lib entry N_CST_WINSRV

The call stack is visualized by indenting each level, so you can see when a method or event is entered and exited. It’s a lot of data to wade through, and basic text editors like Notepad and Wordpad aren’t going to help you mine for any nuggets of truth in there.

PBLPeeper to the rescue!!

PBLPeeper's DEBUG file viewer

In the figure above, I’ve loaded PBLPeeper with the PB 11.5 workspace and target that were used to generate the .DBG file, then went to the Trace tab. This prompts me to load the .DBG file. As the illustration shows, you get a two-paned presentation. The contents of the .DBG file are loaded into the left-hand pane (with handy collapse/expand capabilities). When you click on any line in the .DBG file, the Powerscript for that specific event or function is automatically loaded into the right-hand pane. With this technique, you get to see the actual line of code, in context with its entire script. PBLPeeper handles overridden functions/events as well.

One of the benefits that the /PBDEBUG technique has over the step debugger is handling POSTed events/functions. Since a posted call is simply placed on the Windows message queue, it gets processed the very next time the application yields. If you place a debugger STOP after a call has been posted, but before it has a chance to execute, it will fire “out of place”, and your application will not behave as you intended. The /PBDEBUG approach does not interfere with the Windows event flow, so even posted events/functions can be debugged.

Enjoy!
-Paul-

Advertisements

About Paul Horan

Software Technology - lots of experience with Sybase and IBM mobility/cloud offerings.
This entry was posted in PowerBuilder, Software and tagged , , , , . Bookmark the permalink.