31
TIDE and Tibbo BASIC User Manual
©2000-2008 Tibbo Technology Inc.
The yellow arrow over the red dot merely marks the program pointer; a breakpoint
is always marked by a red dot.
Where a Breakpoint May Be Placed
A breakpoint may be placed only on a line which contains executable code; before
compiling your project, you could place breakpoints anywhere. However, on
compile, these breakpoints will be shifted to the nearest lines following them which
contain executable code.
You could add breakpoints to your code at any time -- even while the code is
running. However, while the code is running, you may only add breakpoints next
to lines which contain executable code. If you click next to a line which does not
contain executable code, the closest line following this line which does contain
executable code will get a breakpoint.
You may have up to 16 breakpoints in your entire project. Breakpoints are saved
when the project is saved.
Adding breakpoints slows down the performance of the Virtual
Machine. Having 16 breakpoints will have a noticeable effect on the
speed of execution of your program.
Toggling Breakpoints
Breakpoints may be toggled (set/cleared) by putting the cursor in the line in which
you wish to place (or remove) the breakpoint and pressing F9 or selecting Debug >
Toggle Breakpoint. Alternatively, you may also toggle a breakpoint by clicking on
the margin of the code at the point in which you wish to have a breakpoint.
You may remove all breakpoints from an entire project (including any files which
are not currently open) by selecting Debug > Remove All Breakpoints.
4.1.8.4
The Call Stack and Stack Pointer
During the execution of a program, procedures usually call other procedures. The
calling procedures are not just left and forgotten; they are placed on the call stack.
The call stack can be toggled by View > Call Stack. It lists the sequence of
procedure calls which lead to the current procedure (the one in which the
is located). The current procedure is listed at the top of the stack. Once
it finishes executing, execution returns to the caller (the procedure one line below
in the stack). In the caller procedure, execution resumes from the line immediately
following the one which called the procedure which has just ended.
So, if the procedure (event handler, actually) on_timer called the procedure
error_handler, which in turn called the procedure write_logfile, our call stack
would look like this:
30