4D v16

Tracing and debugging

Home

 
4D v16
Tracing and debugging

Tracing and debugging    


 

 

In addition to the manipulations explained in the video, you should also note that:

4D can run interpreted and compiled databases.

In all cases, we recommend that you check the syntax of your development projects using the compiler.

Note: tracing is only available with interpreted databases. Obviously, in a compiled/merged database, we do not have access to the source code. Only users referenced as developers (belonging to a group that has access to the Design environment) can enable tracing.

In addition, the debugger also lets you:

  • modify data in fields and variables being executed
  • add temporary break points, conditional break points, and so on
  • run code (Warning: this is risky!)
  • display table and field numbers
  • remove all displayed expressions
  • choose the information to be shown in each area of the editor
  • and so on.

Most of the things mentioned above can be accomplished using the context menu (right click)

When using the TRACE command in the code, you can stop "tracing" using the NO TRACE command.

A break point is a red dot that you place by clicking in the row number column next to the row where you want 4D to start tracing. It is linked with the row where it is placed.

You can condition break points (ALT-click when creating a break point or on one that already exists). Conditioning is done by formula or depending on a certain number of passes.

Break points can also be temporarily disabled.

You can use the Runtime explorer to remove break points placed in the code without actually returning to the method concerned.

In this video, we're going to learn how to display and work with the debugger.

You use the debugger to trace and check whether our programming meets functional expectations.

It lets you check:

  • the status of the memory
  • the value of the variables
  • the current records and selections of each table
  • and the code by running it while tracing.

We're going to reuse the form with the variables to explore the debugger.

We'll add a break point (we'll come back to this later) and display the form.

When we use buttons that are not within the trace mode, execution takes place normally.

If we click on a button that is within the trace mode, the debugger appears.

We can define 5 areas in the Explorer:

1°) The source code pane: this shows the method being executed. Here we can:
  • place and remove break points
  • drag the yellow cursor indicating the next row to execute up or down (so it is possible to go back to the code that was already executed)
  • move the mouse over a field or variable to display its contents
  • click on an object and move it within the Expression area

2°) The 2nd area concerning navigation buttons, and we'll cover it more thoroughly later on. A help tip explains what each button does.

3°) The Custom watch pane area here

4°) The watch pane contains all the expressions available in 4D (tables, field, constants, variables, processes, and so on)

5°)  The call chain pane represents the chain of methods that let us get to the program displayed.

We're going to stop the method execution.

There are 5 ways to display the debugger deliberately:
1°) By inserting the TRACE command in a method. Whenever the TRACE command is found, the debugger is displayed automatically.

2°) By placing a break point: that's what we did on this button here.

3°) While using the program (during execution), you can use the following shortcuts:

  • "Alt + Shift + right click" on Windows
  • or "Command + Alt + Ctrl + click" on Mac

The list of processes appears.
For the moment, we are tracing in the main process; later on, in the case of multi-process operation, you can choose which process to trace.
So we chose the main process and if we click on "Declarations", automatically the trace mode appears and we can see the contents of the POP1 variable.
We can enlarge the window of the trace mode.
We can memorize the position and the variables stored there and even change the values there directly. So if we want to change the value of v1, we can put 300 and here another version of the 3rd phrase.
Obviously, if we retrace the main process and we assign values to the array, when we go by here again, on the 3rd row we'll now have the value that was set here.
As said before, it is possible to move the cursor back up in order to execute the rows again.

4°) In the Design environment, when you execute a method, you can click on the execution button and choose "Run and Debug", within the application process or in a new process. In this case, the trace mode appears automatically so that we can debug the method.

5°) And finally, one last way to show an equivalent to the trace mode is to use the Runtime Explorer by pressing "Ctrl+Shift+F9". The Runtime Explorer (which is only available to developers and other authorized users) lets you display the list of processes, for instance the main process, and then trace it.
From here, when we click on a button that executes code, we'll see the trace mode appear with the line of code that is about to be run.

So there are 5 ways in all to display the trace mode.

The most frequent of these are:

  • break points
  • and keyboard shortcuts.

The debugger also appears, usually unintentionally, when 4D cannot run your code (such as with syntax errors, typing errors, and so on). It displays a message so that you can switch to tracing.

Let's take an example in the navigation method: if we remove the = here and save, 4D displays an error and offers to trace the code in order to show us the problem.

 
 

 
PROPERTIES 

Product: 4D
Theme: Tracing and debugging

 
HISTORY 

 
ARTICLE USAGE

Self-training ( 4D v16)