04-08-2025, 10:30 PM
There was someone with a question about reading past CHR$(26) and INPUT over at .com's forum, and then they popped in and asked me a question about it, so I thought I'd write up a quick little demo for it.
Provided the above works for you guys without glitching (it has embedded CHR$(26) characters that may not copy/paste properly with the forums, it should showcase a file with CHR$(26) Logical EOF markers embedded in it.
If it doesn't copy/paste properly, grab the txt file below and remark out the DATA statements and where we write those to disk. Just use the provided file and read it without any issues.
Now, when this runs, it reads our data until it finds a CHR$(26) logical EOF marker. In this case, that EOF *isn't* the actual end of file. It's simply the end of one stream of data inside that file. All one has to do is simply SEEK past the current position for that Logical EOF marker and then they can continue on with reading the data as intended.
*WHY* would someone want to do this?
Back in the day, folks were PICKY about such things as disk space and memory and everything else. When your floppy only held 360k bytes of data, you tried to pack it as tightly as possible. Instead of writing multiple files of 30ish bytes each, which would use 512 bytes per sector each, folks would pack that info into a single file, which would use the *same* 512 byte sector each.
Other folks would also use CHR$(26) as I have here above -- as data delimiters for tables and such. It's fairly rare to see CHR$(26) in use today as those memory and disk constraints aren't as restrictive as they used to be, but QB64 has always tried to be backwards compatible and as such it still reads and accepts those CHR$(26) characters as Logical EOF markers.
Easiest work around?
When EOF is called, *also* check LOF. If the EOF is triggered and you're not at the EOF, it's a LOGICAL End Of File marker. Use SEEK to move ahead past it and then keep reading your data according to whatever the heck you're supposed to do with the new stream of info.
That's really all there is to it!
Code: (Select All)
Data Steve,50,555-555-0001
Data Pete,70,555-555-0002
Data Bplus,40,555-555-0003
Data Matt,20,555-555-0004
Data EOD
Open "testfile.txt" For Output As #1 'create a data file
Do
Read dta$
If dta$ = "EOD" Then Exit Do
Print #1, dta$;
If InStr(dta$, "") Then _Continue Else Print #1, ",";
Loop
Close #1
Print "NAME", "AGE", "PHONE"
Open "testfile.txt" For Input As #1
Do
Do
Input #1, dta$
Print dta$,
Loop Until EOF(1)
Print
p = Seek(1)
If p < LOF(1) Then Seek 1, p + 1 Else Exit Do
Loop
Provided the above works for you guys without glitching (it has embedded CHR$(26) characters that may not copy/paste properly with the forums, it should showcase a file with CHR$(26) Logical EOF markers embedded in it.
If it doesn't copy/paste properly, grab the txt file below and remark out the DATA statements and where we write those to disk. Just use the provided file and read it without any issues.
Now, when this runs, it reads our data until it finds a CHR$(26) logical EOF marker. In this case, that EOF *isn't* the actual end of file. It's simply the end of one stream of data inside that file. All one has to do is simply SEEK past the current position for that Logical EOF marker and then they can continue on with reading the data as intended.
*WHY* would someone want to do this?
Back in the day, folks were PICKY about such things as disk space and memory and everything else. When your floppy only held 360k bytes of data, you tried to pack it as tightly as possible. Instead of writing multiple files of 30ish bytes each, which would use 512 bytes per sector each, folks would pack that info into a single file, which would use the *same* 512 byte sector each.
Other folks would also use CHR$(26) as I have here above -- as data delimiters for tables and such. It's fairly rare to see CHR$(26) in use today as those memory and disk constraints aren't as restrictive as they used to be, but QB64 has always tried to be backwards compatible and as such it still reads and accepts those CHR$(26) characters as Logical EOF markers.
Easiest work around?
When EOF is called, *also* check LOF. If the EOF is triggered and you're not at the EOF, it's a LOGICAL End Of File marker. Use SEEK to move ahead past it and then keep reading your data according to whatever the heck you're supposed to do with the new stream of info.
That's really all there is to it!
![[Image: yeah-beavis.gif]](https://media1.tenor.com/m/rOo8aOs52qkAAAAd/yeah-beavis.gif)
