GAB Debugger

From GAB Help
Jump to: navigation, search

Overview

Syntactical errors, logic errors, and unforeseen/unhandled conditions can debilitate a program. Debugging is the process by which these factors can be identified. The GAB Executor (OCTSRS.EXE) includes a step-wise debugger for analyzing the inner workings of Global Application Builder (GAB) programs.

Invoking the GAB Debugger

The GAB debugger can be invoked by placing a blank file named CION.DO, in the root of the C: drive, or by enabling GAS debugging from within Global Shop. When a hook has an associated GAS program, the GAB Debugger will appear (as pictured below). Can also be called in the GAB program by Function.Intrinsic.Debug.InvokeDebugger

Miscellaneous Notes:

There are multiple versions of Cion.do (this is the file created in the users C:\ to invoke the debugger)

CION.DO

this file will invoke the debugger for all GAB programs run on a particular computer

CIONBOE.DO

this file will invoke the debugger for all GAB programs run on a particular computer, starting in the STOP mode. BOE stands for Break on Entry

CIONxxx.DO

this file will invoke the debugger for all GAB programs run from a particular terminal number (this is important for debugging selectively in Terminal Services). xxx is the GSS terminal number.

CIONxxxBOE.DO

this file will invoke the debugger for all GAB programs run from a particular terminal number (this is important for debugging selectively in Terminal Services), starting in the STOP mode. xxx is the GSS terminal number.


Gab debugger 1.jpeg


GAB Debugger Screen

Using the Debugger

GAS programs are interpreted. As such, they evaluate and execute the lines of code at runtime, rather than at compile time. The debugger will let you watch the evaluation and execution of your code.

Current Line/Arguments

The two textboxes below this line are the Current Line (displays the full text of the code line in the GAB execution engine) and then the Arguments are parameters passed to the called function.

GAB Program:

This displays the current GAB Program being executed.

Options on the Left

Step Execute- If checked then once the first Function.Intrinsic.Debug.Stop is reached the program will then step through a single line of code when the user clicks on the Run button at the bottom Left of the screen. To disable the step mode debugging, uncheck the box and click “Run”. Step execution breakpoints can be placed in the code at design time using PROGRAM.SUB.CONTROL.STOP; this is analogous to checking “Step Execute”, but will only work if the GAB Debugger is already running.

There is a toggle bar next to “Step Execute” that allows the user to “Step” ahead in the code.

Ignore Breakpoints – Allows the user to check this box if they are done error checking and want to run through the code without hitting any additional breaks/stops.

Options on the Right

If the “Evaluate” checkbox is checked, argument variables or properties are evaluated to their underlying value.

If the Refresh Variable Watcher is checked then the Variables will refresh with each line execution

If Show Line numbers is checked then the debugger will tell the current line being executed

If Show Unhandled Control/Aux Events, the debugger will list all events and controls that have not been executed.

Trappable Error Information

Shows the error number and the description, if the error is trapped.

Icons

- First “?” Bubble launches GAB Help

- Second “?” Bubble launches GAB Forum

- Notebook launches script in Notepad

- Pencil allows the user to edit the next executable line in the script

- Show Caller Information – Displays the caller information for the Core screen being accessed.

Individual Arguments

Gives a listing of what is being given on any current line.

Variable Watcher

The “Variable Watcher” section allows you to peruse the local, static, global variable stacks, Function Args, Function Return, and Passed variables. Variable arrays are shown fully expanded with all elements listed.

Local

shows the local variables for the current program and the value given to each.

Static

shows all the Static Variables for the GAB Program

Global

Shows all the Global variables and their values for the GAB Program

Function Args

Function Return

Passed

These are variables passed from Global Shop to GAB

Immediate

This section allows the user to see what the GAB program is processing such as initializing controls, Creating the screen, Destroying references, etc.

Object Watcher

ODBC – Shows connections, and recordsets

Other Objects – Shows other types of objects being used by the program.

Recently Executed Lines

This section displays the last 16 commands executed. The “Subroutine” column shows which subroutine the executed line was in. Since GAS programs allow the calling of subroutines, and are driven on an event model, visibility of the calling subroutine is useful. The column immediately to the right of the “Subroutine” column shows the line number of the executed line. This is useful when watching control structures, like conditional logic or loops.

Buttons across the bottom of the screen

- Run – Runs the program by either starting it back up after a stop or stepping through the “stop” to debug.
- Step Out - is used if you want to continue step executing the original subroutine, but not a called subroutine within the original subroutine.
- Exit can be used to terminate a running GAS program at any time.
- Output – If pressed will continue to show the output on the screen, if unclicked then the output is no longer updated on the Debug screen.

Last Event Fired – shows the last click, sub called, etc.

Debug Stop

The debug level will allow you to set what stops to ignore and which will actually cause the program to break.

- F.Intrinsic.Debug.Stop – When debugger is running the code will break at this point. You can then step execute through your script

- F.Intrinsic.Debug.Stop(DebugLevel) – Alternate syntax. This will cause the code to break if the debug level is equal to or lower than the set level.

- F.Intrinsic.Debug.Stop(DebugLevel, Message) – Alternate syntax. This will cause the code to break if the debug level is equal to or lower than the set level. It will also display a message at this point. The message can be straight text or a variable.

- F.Intrinsic.Debug.SetDebugLevel(DebugLevel) – Sets the debug level as a long

*Coming Soon*- There will be an ambient variable coming for the debug level. Also a cion.do that will allow you to set the debug level outside your code.
 Example-
F.Intrinsic.Debug.SetDebugLevel(5)

V.Local.sQuery.Declare(String)

V.Local.iPTLine.Declare(Long)

V.Local.sLine.Declare(String)

F.Intrinsic.Control.If(V.Global.bBusy,=,False)

V.Global.bBusy.Set(True)

Gui.F_Main.gsfgMM.ReadRow(V.Args.key,V.Local.sLine)

F.Intrinsic.string.Split(V.Local.sLine,"*!*",V.Local.sLine)

F.Intrinsic.debug.Stop(1)

F.Intrinsic.Control.If(V.Screen.F_Main!txtPTID.Text.trim,<>,"")

F.Intrinsic.String.Concat("SELECT TOP 1 PT_LINE FROM ATG_PT_INFO WHERE PT_NUM = ",V.Screen.F_Main!txtPTID.Text," ORDER BY PT_LINE DESC",V.Local.sQuery)

F.odbc.Connection!conx.OpenRecordsetRO("rstX",V.Local.sQuery)

F.Intrinsic.Control.If(V.odbc.conx!rstx.EOF,=,False)

V.Local.iPTLine.Set(V.ODBC.conx!rstX.FieldVal!PT_LINE)

F.Intrinsic.Control.EndIf

F.odbc.conx!rstX.Close

F.Intrinsic.Math.Add(V.Local.iPTLine,1,V.Local.iPTLine)

F.Intrinsic.String.Concat("SELECT * FROM ATG_PT_INFO WHERE PT_NUM = ",V.Screen.F_Main!txtPTID.Text," AND PT_LINE = ",V.Local.iPTLine,V.Local.sQuery)

F.ODBC.Connection!conx.OpenRecordsetRW("rstX",V.Local.sQuery)

F.Intrinsic.Control.If(V.ODBC.conx!rstx.EOF,=,True)

F.ODBC.conx!rstX.AddNew

F.ODBC.conx!rstX.Set!PT_NUM(V.Screen.F_Main!txtPTID.Text)

F.ODBC.conx!rstX.Set!PT_LINE(V.Local.iPTLine)

F.ODBC.conx!rstX.Set!PT_USER(V.caller.User)

F.ODBC.conx!rstX.set!SIGNED_OFF(0)

F.ODBC.conx!rstX.Set!COMPLETED_FLAG(0)

F.Intrinsic.debug.Stop(5, V.Screen.F_Main!txtPTID.Text)

F.ODBC.conx!rstX.Set!MM_NUM(V.local.sLine(0))

F.ODBC.conx!rstX.Update

F.Intrinsic.Control.EndIf

F.ODBC.conx!rstX.Close

F.Intrinsic.Control.CallSub(Loadptgrid)

F.Intrinsic.Control.CallSub(Loadgrid)

F.Intrinsic.Control.else

F.Intrinsic.UI.Msgbox("A New Transmittal Must First Be Added")

F.Intrinsic.Control.endif

V.Global.bBusy.Set(False)

F.Intrinsic.Control.endif 

Caller Information

One of the benefits of using GAB is its tight integration with Global Shop screens and processes. This integration is achieved by sharing all screen and procedure information with GAS programs. This information is displayed when the “Display Caller Info” button is clicked from within the debugger. The caller information screen is pictured below.


Caller info.jpg


Caller Information

A full explanation of the VARIABLE.CALLER and VARIABLE.PASSED namespaces is available in the standard GAB help documentation.

To sort Columns, simply click on the column name to sort by that field.

To Copy Id to the clipboard simply double-click on the ID field you want to copy, and then paste it into your GAB script.

Using the Debugger

GAS programs are interpreted. As such, they evaluate and execute the lines of code at runtime, rather than at compile time. The debugger will let you watch the evaluation and execution of your code. The “Current Line” textbox displays the full text of the code line in the GAB execution engine. The parameters passed to the called function are listed in the “Individual Arguments” section. If the “Evaluate” checkbox is checked, argument variables or properties are evaluated to their underlying value.

The “Variable Watcher” section allows you to peruse the local, static, and global variable stacks. Variable arrays are shown fully expanded with all elements listed. Additionally, the passed and return variables are listed.

The “Recently Executed Lines” section displays the last 16 commands executed. The “Subroutine” column shows which subroutine the executed line was in. Since GAS programs allow the calling of subroutines, and are driven on an event model, visibility of the calling subroutine is useful. The column immediately to the right of the “Subroutine” column shows the line number of the executed line. This is useful when watching control structures, like conditional logic or loops.

When the “Step Execute” checkbox is checked, the GAB Debugger will only execute a single line of code. To proceed with the code execution, the user must click the “Run” button. To disable the step mode debugging, uncheck the box and click “Run”. Step execution breakpoints can be placed in the code at design time using PROGRAM.SUB.CONTROL.STOP; this is analogous to checking “Step Execute”, but will only work if the GAB Debugger is already running.

The “Exit” button can be used to terminate a running GAS program at any time.

The following debugger feature has been added to the 433 version of OCTSRS.EXE:

A "Step Out" button has been added to the debugger. When in a called subroutine of a GAB program, the "Step Out" function will allow you to execute without stopping, until it has exited the current subroutine. At that time, the program will resume execution in step debugging mode.

Note: The "Caller Information" button has been relocated to the top half of the screen to make room for the "Step Out" button.

Note: If you double-click on a passed data line, the selected ID will be added to your clipboard as:

Variable.Passed.SelectedID