SIMPOL Documentation

This dialog box manages the active project breakpoints status. A breakpoint is a mark added to aid debugging. When the application reaches that line, it will interrupt the execution of the program. The line containing the breakpoint will not be executed.

To add or remove a breakpoint in the active document, move the caret to the line and press the "Inserts/Remove Breakpoint" button. The breakpoint is displayed in the editor as a maroon circle on the left of the line. When a breakpoint is added, it is active for all the threads of the program. By default there is no condition for the break, i.e. the execution will break in all cases. It is possible to add a break condition, using the "Condition to stop execution", field, which is explained below.

The Breakpoint Manager dialog box shows a table with information on all the project breakpoints. There is a row for each breakpoint. The following table explains each component of the Breakpoint Manager dialog box:

This is only available if there is an active project. This dialog box represents a tree view of all the calls among functions in the project. Each node represents a function. If the dialog box is opened from "Menu/Tools/CallGraph", the parent function calls the child one. If the dialog box is opened frome "Menu/Tools/CallerGraph", the parent function is called by the child one.

The dialog box has a combo box for the user to select the project function that will be the root of the tree. Once this is selected, the tree will be created with the functions that call or get called by the parent node and so on.

Each node displays the name of the function that it represents. At the bottom of the dialog box the file path of the function is displayed and the function prototype. If the user double clicks on a node, the editor will open the source code file where the function is located and show the function definition. This will happen only if the source code file is available.

This is only allowed if there is no active project. Using this dialog box, the user can check if the structure of a project definition file (a smj file) is valid or not.

The dialog box has an entry for the project definition file path. After entering the file path, the button "Check consistency" becomes active. This button will check the consistency of the file and will display the result in the box below the button. There are two buttons below the result box. The first button edits the project file definition. The second button loads the project that will be active if the project definition file is OK. If there are problems with the project definition file, the user has to edit it, make the appropiate changes and save the modified file. After that the user must check the consistency again repeat the process until the project description file is valid.

This dialog box will always show up if the user tries to load a project with an invalid project desciption file.

This dialog box stores general application properties. This information is stored in the windows registry.The following properties can be modified:

This dialog box allows the user to change the settings for a language. The language settings are stored in a .ini file. For example, the language settings file of the XML language is XML.ini.

This dialog box has the following tabs:

This dialog box is used to create a new Superbase NG project. It is used to set the properties of the new project.

These are the options:

This option is only available if there is an active project and the user is not debugging it. The information recorded from a debug session is displayed here. It is a very powerful feature that shows the developer the bottle-necks of his SIMPOL program and, as a result, he can remove them and improve the program's performance. At the top left of the dialog box there is a checkbox to enable or disable this feature. If it is enabled, execution in debug mode will go a bit slower in order to record the function calls, time spent in each function, and so on.

There is a box at the top where the user can enter a number of microseconds. This is the maximum amount of time that will be recorded for a statement being executed. The reason behind introducing this cutoff is that a multitasking operating system can pause the execution of a process in the middle of an statement. In this case the time the statement takes to be executed is actually its own time plus the time the microprocessor doing other things. So if we know, for example, that a part of our statement is going to last less than 500 microseconds, we can set this time as a cutoff. This will probably remove all the time the microprocessor is out of our process in the profile report, or at least, the majority of it.

The most important thing in the dialog box is the table, where the recorded information will be displayed after a debug sesion. There is a row per function. The columns of the table are explained below:

This is only available if there is an active project. It displays the project properties, and allows the user to edit them. The project settings are stored always in a file with smj extension. The name of this file is the name of the project.

The dialog box shows the following information:

function main prototype: main(string s, string s2)
command line: "hi  bye" 123

Output CGI format:
  cgi.output(%s + "{0D}{0A}", 1)
Line in a SIMPOL server page file:
  <TH>Hello </TH>
Line in the source code file associated
  cgi.output("<TH>Hello </TH>" + "{0D}{0A}", 1)
              

This dialog box is opened when the "add/edit target" button in the Project Manager dialog box is pressed.

On the left there is a list of target folders and on the right there is a list of shebang lines. Below each list is an edit box where the user can modify the information (target folder or shebang line). There are buttons to add the content of the edit box to the appropiate list, remove an entry in the list or add the content of the entry in the list to the edit box. The list entries are stored in the windows registry. There is also a checkbox to activate or deactivate the target. Finally, there is an entry in the target area to enter the target file name. Note: This is usually the name of the project output, but it can be overwritten.

This is only available when a project is being debugged. It is a very powerful feature that allows the user to evaluate expressions and to display the runtime object content.

The dialog box has an expression entry at the top. At the center of the dialog box there is the object viewer, which displays the result of the expression evaluation in a tree view. If the user enters the name of a function variable that contains an object as an expression, it will be displayed in the object viewer. The object tree root node represents the object in the variable. There will be a child node per object contained in the root object, and each of these nodes will have a child node per object it contains and so on. This allows the user to inspect the object completely.

The object viewer has two sides. The left side is where the tree nodes are located, and the right side is where the value of the object, if applicable, is displayed. Typically the objects with values are the basic types: boolean, integer, string, number and blob. But each object has an internal value that can or cannot be used. For example, the standard object "date" has an integer as internal value to store the date value.

On each node the name of the variable or type property that holds an object, the type of the variable or type property holder and an internal ID of the current object is displayed. If there are two nodes with the same internal ID in a tree, it means that they refer to the same physical object. All the objects have a child type object. This type object transports information about the structure of the parent object. So the value of the type object will be the type the parent object has at runtime. For example, if the type of a variable is a tag type "type(MyType)" then the object held in the variable can or cannot be a "MyType" object. It is displayed in the child type object.

If an expression is not a variable or a type propery, result will be displayed in the object viewer as a tree with just one node and of another color.

The expressions can contain variables and type property names with boolean, integer and string constants. There are many operators that can be used in an expression, so we can evaluate very complex ones at runtime and retrieve interesting pieces of information. (The expression rules are described in the the section called “Expression evaluation help”)

There is an edit box at the botton of the dialog box. When a node of the object tree that holds a basic object is selected, the value will be displayed in the box, and the user can modify it. After a value modification, the user has to press the "Set Value" button if he wants to update the object tree with this new value. After editing and changing several values in the object tree, the user must press the "Save new values" button to save all the changes in the physical objects.

When editing a blob value, a new window appears at the bottom of the dialog. This new window will display the ASCII translation of the binary content of the blob. This is quite useful if the blob contains ASCII information, e.g. ASCII text.

The Thread Manager is the place to modify the running status of a thread whilst debugging a SIMPOL program.

The debugger enumerates the threads sequentially as they are created by the program, with the first one created being known as "Thread 1"

The Thread Manager displays the running status of all the threads in the program and the functions that they are executing at the time the thread manager is opened. The user can also suspend or resume any thread and change the debugger focus to another thread. This means that Step Into, Step Out, Run to Cursor etc. will affect this new thread.