Sprezzatura :: Making Databases Happen

By Sprezz | Tuesday, 26 April 2016 15:25 | 3 Comments

This is going to be one of those blog posts that will either have you saying "Well d'uh everybody knows that" or "Wow what a neat trick". I know that I fell into the latter camp which is why I'm blogging it.

Aaron and I are working together on a new tool for network administrators and it has been a fun ride. Recently we had cause to have Aaron TeamViewer into my machine to help debug a specific routine. So I watched as he took over and waited for him to fire up the System Editor, open the program, insert a DEBUG, compile and run. This is how I've traditionally done it and of course you have to be really careful to remember to remove the DEBUG before shipping the code to anybody. (Or run your release through a release checker that warns of the DEBUG opcode in object code). Instead he performed the neat trick documented below. When I expressed admiration he was incredulous. "I've been doing it this way since OI 2.0" quoth he.

So allow me to present an illustrated guide to debugging without DEBUG statements.

Firstly open the engine window

and click on the Debugger button. Now give focus back to the System Editor or any active OI screen in a way that causes it to trigger an event. The debugger will be invoked.

Now from within the debugger, from the File Menu choose "Open Stored Procedure" and select the routine you wish to debug

Scroll through the code and select your break point in the usual way by double clicking on a line of code

then click on the Run button or press F5 to continue.

The system will return to "Normal". Now invoke the program you wish to debug (for simplicity I will just illustrate by running from the System Monitor)

et voilà - the program breaks at the nominated break point.

This is so cool - it's slightly faster than inserting a DEBUG and you don't run the risk of forgetting to remove the statement!

3 Comments:

How is the 'debug' stopped - Does it only activate the once in the run.

Is it is only activated for your session on a network, ie. if other users were to run the program before you do would the debugger invoke. (If not, then great way to debug in a LIVE environment)

By Barry Stevens, At 4 May 2016 at 23:47
Without meaning to state a tautology, the debugger works like the debugger.

This is no different than setting a breakpoint after the debugger has loaded from a debug statement. The only difference here is that you're setting the breakpoint before you enter the code.

When you set a breakpoint, you tell the debugger to continue executing until you get to this point, then stop and show the debugger. A breakpoint is just a breakpoint. Once you're in the debugger, you can load any SYSOBJ row with source and symbol rows, and set the breakpoint. Just like when you run through the debugger, it jumps through subroutine and comes back into your code with the breakpoint set. This is the same.

The idea here is that you know you're going to call the WINDOW_COMMUTER routine, and there'a a problem with it you want to trace. So, you open up the debugger, load in the source code, and set a breakpoint. No need to recompile the code with a debug. In fact, you really don't want to recompile the code, because you don't know if recompilation would change something. This allows you to run the code, as is, right now.

As for other workstations, we're back to "a breakpoint is just a breakpoint". Breakpoints are local to each OENGINE, even if you're running multiple instances of OI, so what happens in one OENGINE stays in that OENGINE. A breakpoint is cleared when you close OENGINE, recompile that code, or manually remove the breakpoint.

By APK, At 6 May 2016 at 16:06
The easier way is to select Debugger from the OI Tools menu. If from new IDE opens immediately if non IDE then you need to click on another screen that will generate an event.

By Barry Stevens, At 13 May 2016 at 19:55

3 Comments:

Post a Comment