Hi George On Saturday 18 February 2012, 9:56George Gwilt 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: 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
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. Hi Malcolm On Friday 17 February 2012, 21:35 Malcolm Cadman wrote: > Also useful to use and declare integer values, wherever you can, at the start > of the BASIC program - which is "value%" rather than "value". Yes, I agree. There is a particular reason for this. Suppose the compiled program stops somewhere with an out of range error. The SuperBASIC version could then be run using the same input data, duplicate the error and stop at exactly same place. The procedure "how" would then be run to discover the call hierarchies that got the program to that point. Variable values could then be examined with the view to pin-point the cause of the error. However, if using IMPLICIT% value, then the SuperBASIC version would be using floating point variables and the same error would not be produced and so would not stop at the same place. Michael Bulford _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm