traceback

[Stuart]

It would be really handy to have a simple traceback that showed from where a subprogram had been called when an error occurred. Python has such a thing which makes tracing errors a little easier. I appreciate implementation will depend on how the innards of AnnedRDS work.

[cicciocb]

There is an "undocumented" feature, a kind of TRACE ON in the old basic, that print all the lines on code in the console as soon as they are executed; obviously this delay the program but you can see the sequence of the line executed.

About the possibility to show the call stack, this should be possible as the line position of the caller is stacked (because the called subcode must know where to return )

[BeanieBots]

Looks like there are quite a few "Easter Eggs" lurking in Annex

[cicciocb]

This is quite easy to find

Simply type debug 1 to enable and debug 0 to disable

[Electroguard]

You could create your own 'breadcrumb trail' of where the program has been and just come from.
(an excerpt from Hints, Tips & Gotcha's) on old Annex website... https://www.myrapidq.it/annex_mirror/us ... cha-s.html
TIP - Breadcrumb Trail
To aid debugging, after each subroutine declaration (eg: buttonpress:) add (eg) branch$= plus the name of the subroutine (eg: branch$="buttonpress"), then you can add wlog branch$ for any subroutines that you want to keep track of, eg:
buttonpress:
branch$ = "buttonpress": wlog branch$
It is quick and simple to do, and allows you to leave a convenient 'breadcrumb trail' of your scripts movements.

You don't have to wlog branch$ every time. A more selective way to use it would be to wlog branch$ from elsewhere on an 'as-needed' basis.
So you could add the ramcheck user sub below, then simply add the line ramcheck to various 'suspect' locations in your script to show the status of memory from those locations.
sub ramcheck
wlog "Ramfree from " + branch$ + " = " + str$(ramfree)
end sub

The 'breadcrumb trail' can also be used selectively to allow taking different actions depending on location...which comes in VERY handy for button presses.
Instead of re-assigning button interrupts to different event handler branches according to different parts of your script, the breadcrumbs allow just having one event handler per button, which simply branches according to the value of the subroutine branch$ which invoked it.

Edit: It's not even necessary to wlog the 'breadcrumb' branch$ 'while the program is running to find the cause of a Halt On Error problem, simply enter the name of the breadcrumb branch$ into an Editor Var window afterwards to see what subroutine caused the 'Halt On Error'.


For debugging purposes, you might add...
wlog "buttonpress from " + branch$
at the top of your event handler to flag where each buttonpress originated from.
Then for operational purposes you could use either IFs or Select Case statements to branch as appropriate depending on the value of branch$..

To emphasis that usefulness...
I am using the breadcrumb trail with 3 different buttons to provide menu navigation and selections, plus each button is able to differentiate between short or long presses to take different actions for any branch$ locations. Each button uses 2 sets of CASE branch$ statements, one for any short-press branch$ of interest, another for any long-press branch$ of interest. Additionally the breadcrumb trail offers the debugging bonus of being able to clearly see which button causes what branching to where.

Electroguard 5/10/18
-----------------------------------