I've been using version 6.248 of GL Basic for the longest time and didn't really need to upgrade it since it has worked fine with everything I threw at it. Well, I come to the point where I needed to do some extensive work with files and started using openfile() and it's related functions. What I found is that some of the READ functions work and some fail as in the compiled app just closes as soon as it starts. A similar close as if you referenced an array with an index that is out of it's bounds though that's just an example to maybe narrow down the issue at hand. It could just be something I'm over looking. Anyway, I decided to install the latest version 8.148 in hopes that it would be a bug that got fixed since the last version I was using but this also had the same behavior. A search brought up a few topics on the matter but they didn't bare any fruit.
Below is some sample code I wrote for this issue and it lists the commands that work and the ones that exhibit the problem. I did not test any of the WRITE commands yet though except WRITEUBYTE and it is working correctly. I mainly need to use the LONG versions of the functions. The test file I used is not included, it was only 2k containing some random text.
GLOBAL storage%[]; DIM storage[1]
GLOBAL storageieee
GLOBAL storage$
GLOBAL pos = 0
IF OPENFILE(1,"test.txt",1)
WHILE ENDOFFILE(1) = 0
// Not working
READLONG 1,storage[pos]
//READULONG 1,storage[pos]
//READSHORTIEEE 1,storageieee
//READIEEE 1,storageieee
//READSTR 1,storage$,4
// Working
//READBYTE 1,storage[pos]
//READUBYTE 1,storage[pos]
//READWORD 1,storage[pos]
//READUWORD 1,storage[pos]
//READLINE 1,storage$
WEND
CLOSEFILE 1
ENDIF
WHILE TRUE
PRINT "Test: " + storage[pos],0,0
PRINT "Test: " + storage$,0,10
SHOWSCREEN
WEND
An update, I tested this on one of my other dev comps and got the same problem so it does not appear to be a system dependent issue.
It originally crashed with me too.
But, I changed my "text.txt" to this:
(The file contains no [CR] or [LF])
1 2 3 4 5 6 7 8 9 10
If the 'READLONG' command reads an invalid character for that data type, or it can't read the expected number of bytes for strings, then I'm guessing that's what's causing the crash.
(The error says: "Error: No File")
Interesting. I'll test that out. Reading a long though should just be four bytes irregardless of what each byte is which would lead me to believe that the function is doing something with carriage returns and line feeds that it shouldn't. :blink:
Edit:
Well I just tried that and got the same thing. I guess in the meantime I will just use two word reads combined for a simple solution.
Looks like you are reading past the end of the file? If you read LONG, you have to make sure there are enough left of the file to fit into the variable. If not, I would expect an error if the file isn't the length you expect.
You were right on Moru. The functions that I found to appear bad do work correctly but will fail if you read more data than the file contains at it's end for the particular data type. In the app I'm currently working on I had some simple checking for the remainder bytes which I now know is faulty. It's always something obvious. XD