Hello BobDye,
I first tried to use that DEBUG/BREAK/TRACE business years ago with version 3. The manual says that if DEBUG ON is in effect, then the program will stop when it encounters a BREAK statement (because all it does is to cause an error). Then it says, essentially, that if you want it to do anything else, you have to write an error handler and stuff to find out what happened. A bother of the first magnitude.
Anyway, I couldn't get it to work back then, so I have never bothered with it since.
What I do, after deciding where the error might be, is to insert a few lines right after the suspect variable(s) have been calculated, such as:
sound 900,.3 !------------------
set color 12
print, "Line 123: blah1$= ";blah1$;" blah2=";blah2
get key zz
set color 0 ! ------------------
Obviously this will work.
Every now and then I get tempted to write this as a little SUB but then that's not always as simple as it might seem. So I just insert those few code lines, and run again. Quick and dirty. Once that particular problem is reduced, I just REM them out, in case needed again. Or, just delete them.
If it's something more complicated than that, such as values in an array or a vector, I just have it put the values on the system clipboard, beep and tell me; and then I paste it into a text editor so it can be reviewed.
Sometimes you have to do as the manual suggests, which is to write something to some file, or append it to some file. I do have SUBs for that when it gets that complicated.
The above is fairly quick and easy to implement, and even when my programs wind up a couple of thousand lines long as they usually do, this is still the quickest way to find bugs. It's hassle-free because you know exactly what these little segments are going to do, since you have written them yourself.
Another of my tricks to circumvent this debugging problem is to divide the work up into simple tasks at the very outset, and write SUBs to execute that one little part. Then when that works correctly, I stick it down below the END statement and attack the next step in the program.
This has two advantages; 1. the flow of the program doesn't get cluttered up with long series' of lines of stuff; and 2. you soon find that the same little SUBs get needed over and over many times. So then stick 'em in a LIBRARY. Eventually you will have a 2-thousand line LIBRARY or two that covers just about everything you ever need to do. Then composing a program almost becomes as simple as selecting a series of SUBs to CALL from the LIBRARY.
So, the bottom line is, I have never found out what's wrong with the BREAK/BREAKPOINT thing. I don't think many people fool with it, because in many years of watching this forum I can't recall anyone ever asking about it, and they would have, because it apparently just doesn't work. Another thing that "ain't quite right" is the CHAIN thing. It never worked in accordance with the manual, any there were many many posts on this. Finally someone wrote a revised set of instructions which are now available from the downloads page. It's a little better now, but still not as simple to use as it should be when trying to pass arguments.
Sorry I couldn't actually answer your question, but hope this helps some.
Regards
Mike C.