Memory Access Violation

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|563\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Blitz -> Memory Access Violation
Sat, 03 Aug 2013, 17:10
dna	Hello. The code below gives the error when the loop reaches file #509 for soem reason. There's somthing I'm missing somewhere. .AGAIN Cls:For FX=100000 To S:NF$=Str$(FX):;Print S:WaitKey:End:Locate 50,10:Print FX:Flip:Cls:Next:WaitKey:End K$="KEY":LI=33:CHL=100:FN$="R:\WHK\"+K$+NF$+".TXT":FH1=WriteFile(FN$) Locate 20,20:Print "PROCESSING: "+Mid$(FN$,Instr(FN$,"KEY"),9) For G=1 To LI:For H=1 To CHL RT$=RT$+STR$(FX): Next Next:Flip:Cls:WriteLine(FH1,RT$) CloseFile FN$:Next Print "COMPLETED":WaitKey:End --v I checked to make sure my system was formatted to NTFS since the number is close to the max for FAT -=-=- DNA
Sat, 03 Aug 2013, 18:07
HoboBen	I'm not sure DNA but is it anything to do with RT$ which you keep appending to? Should it be reset e.g. by RT$ = "" just after the "For FX=100000 To S:" bit? -=-=- blog \| work \| code \| more code
Sat, 03 Aug 2013, 20:24
dna	That was not it. I found the problem in the CLOSE FN$ Line It should have read CLOSE FH1. Now it's running and goes past 509. If it's a BUG and should not do that at all then it needs to be posted wherever the BUG reports for BB are listed. -=-=- DNA
Sun, 04 Aug 2013, 04:15
Jayenkai	You'll find these things are easier to track down if you use an ounce of clarity in your code. THIS IS MUCH HARDER TO SP0T THE MISTAKE IN. This Is much Easier To f1nd Where the Bug is -=-=- ''Load, Next List!''
Sun, 04 Aug 2013, 15:18
dna	You are right again Jay but should that syntax even have compiled? -=-=- DNA
Sun, 04 Aug 2013, 17:35
steve_ancell	One major problem that causes hard to find bugz, using semicolon separated code on one line. Try using indentation in blocks of code, you will find bug squashing a whole lot easier.
Mon, 05 Aug 2013, 12:35
dna	You're right again Steve however finding the problem was small compared to why it worked at all. CLOSE FN$ vs CLOSE FH1 The first one should not have worked at all according to the manual that I checked. In my mind the program should have stopped or given a syntax error but it ran until it got up to the 509th file and then it gave an error. That was the bug of which I was referring. -=-=- DNA
Mon, 05 Aug 2013, 15:17
Jayenkai	It's not a bug. A file handle is simply a number. A string, in blitz, can also be interpreted as a number. What's happening is your asking it to "close BANANA" and it goes " I ain't got no banana!!", but decides to continue.. Since the file isn't open, why worry about closing it... This is not a bug, this is a programmer error. If you feel uncomfortable with this methodology, you might want to use a more strict language. -=-=- ''Load, Next List!''
Mon, 05 Aug 2013, 15:22
dna	That I did not know. Do you know if Blitz tries to interpret the string as a number when closing the file? -=-=- DNA
Mon, 05 Aug 2013, 15:54
Jayenkai	These are the sorts of things that I tend to learn through experimenting with a language, and trying out different things. I've found, over the years, that learning and playing and throwing odd things at a language, can result in some interesting methods. I also tend to end up with my own ruleset, when it comes to using the language. At the end of the day, you won't know until you try. Start a small test program, and fling shit at it, until you understand what it's doing, and why it's doing it. Test things. Experiment with the language. See what it is, and isn't doing, and you'll become more comfortable with the ins and outs of the thing you're using. -=-=- ''Load, Next List!''
Mon, 05 Aug 2013, 21:20
dna	I see. So the compiler will do things that are completely undocumented. That's different. -=-=- DNA
Tue, 06 Aug 2013, 01:24
rockford	They are undocumented because the original compiler author didn't expect the end-user to abuse the system and do things that he wouldn't do Of course it's the end-user's job to do these things that shouldn't be done. Just for the sake of testing, you know I haven't used Blitz in years now and can't remember - does it have a STRICT/SUPER-STRICT etc. option?
Tue, 06 Aug 2013, 12:05
dna	There's no strict or Super Strict in BB or B3D. In BMax there might be a command like that. -=-=- DNA