On 18 Feb 2012, at 13:38, Michael Bulford wrote: > >> I use DEBUG 0 and 1 for the same reasons as you and have never had the fault >> you mention. > >> If you could send me, privately, a copy of your program I'll try to locate >> the problem. > > Thanks for your offer of help, this is really appreciated. However, I > believe I have solved the problem. I tried moving the piece of code to near > the beginning of the program, and this solved the puzzle. My guess is that > because my program is over 64k, the DEBUG mechanism could not cope, so that > the fault is actually with Turbo. DEBUG must be using unsigned integers, > when it should be using floating point variables. That is my guess. The > piece of code under question is: >
DEBUG is trapped by PARSER_TASK to see whether code is to be ignored or compiled. If fact in PARSER_TASK the values 0 to 9 (which is the allowed range of DEBUG) are held in an fp variable. > 22268 REMark DEBUG 1 > 22276 DEFine PROCedure how > 22284 LOCal p, scan_rt > 22292 CLS 2 : PRINT > 22300 p = BASIC_L(56) > 22308 REPeat scan_rt > 22316 p = p + 24 > 22324 IF p > BASIC_L(60)-24 : EXIT scan_rt > 22332 IF BASIC_W%(p+18)<>0 > 22340 PRINT "Call at ";BASIC_W%(p+18);" in "; > 22348 ELSE > 22356 PRINT "Stop at ";BASIC_W%(146);" in "; > 22364 END IF > 22372 IF BASIC_W%(p-12) > 0 : IF NOT COMPILED : LIST #1; BASIC_W%(p-12) > 22380 END REPeat scan_rt > 22388 END DEFine how > 22396 REMark DEBUG 0 > With the DEBUG commands REMarked out TURBO will ignore them. With the DEBUG commands not REMarked out the "IF NOT COMPILED" is, of course, not needed. > > This piece was copied from the Turbo Toolkit Demos file, the original > procedure name being How_COME. My idea of using DEBUG was to try and save a > little bit of code, because my program is so large. > > _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
