Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / How to use FileEOF?

Author
Message
tmu
7
Years of Service
User Offline
Joined: 2nd Feb 2017
Location:
Posted: 21st Jun 2017 21:09
Link
I am trying to figure out how to properly use the FileEOF tier 1 command.

Example:



This prints on screen the following:



Which translates to having read the values 1,2,0 from the file. And gotten the corresponding EOF after each read as 0,0,1.

So I have a file with two integers, 1 and 2. I look at testfile.dat on disk and its size if 8. I xxd testfile.dat and see the contents as:

0100 0000 0200 0000

So I guess AppGameKit saves integers to file as 4 bytes each, with the least significant bytes first? So there is actually only 2 integers in the file. But the EOF after reading 2 bytes is reporting that the read is NOT at the end of the file yet. So I have to read a non-existent integer to figure out that the file ends.

Finally the Q: What is the correct procedure to actually use FileEOF? Do i really need to try to over-read (at each possible step..), and if it reports EOF, then discard the last read values (which I guess is 0 since AppGameKit seemingly happily reads non-existing data forever..)?

Back to top
Profile PM
hendron
8
Years of Service
User Offline
Joined: 20th Dec 2015
Location:
Posted: 21st Jun 2017 22:34 Edited at: 21st Jun 2017 22:52
Link
It's just a guess, but I would say that the extra 0 being returned is just AGK's way of suppressing an error from trying to read data that doesn't exist. It does seem a bit odd to me, though. I would think FileEOF would return true when the last of the data has been read, without needing to call another read command.

I don't know if this is "correct" or not, but it's about how I'd do it:

Back to top
Profile PM
nz0
AGK Developer
16
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 22nd Jun 2017 01:15
Link
EOF can have issues depending on how the file you are reading was created.
If you are working with reading binary files, check out a decent hex editor so you can examine the source file to make sure there's no unexpected data in it.

I'm pretty sure that EOF has to make a false read (i.e. not the last value, but a fail)
My Robotron remake
My I,Robot remake WIP
My Defender remake
Back to top
Profile PM Email Website
tmu
7
Years of Service
User Offline
Joined: 2nd Feb 2017
Location:
Posted: 22nd Jun 2017 10:29
Link
This is not how I expect a programming environment to work with regards to EOF but I will update my code since I just need it to work.

@nz0, the "xxd testfile.dat" command I had above, and its output, is actually a hexdump of the file. So given its output and the docs for WriteInteger saying it writes 4 bytes per value, I think there is no issue with a corrupt file or anything else.

Would be nice to have this EOF behaviour information documented on the FileEOF doc page. Currently all the doc websites seems to have their examples broken so not sure if there would be anything there. But the general desc should have it as well.
Back to top
Profile PM
hendron
8
Years of Service
User Offline
Joined: 20th Dec 2015
Location:
Posted: 22nd Jun 2017 18:33 Edited at: 22nd Jun 2017 18:36
Link
I suppose another option would be to write a set of file reading wrapper functions. Something like this:



Obviously you'd need to expand it to include the other data types and file functions.
Back to top
Profile PM
PartTimeCoder
AGK Tool Maker
9
Years of Service
User Offline
Joined: 9th Mar 2015
Location: London UK
Posted: 22nd Jun 2017 23:47 Edited at: 22nd Jun 2017 23:58
Link
Quote: "Would be nice to have this EOF behaviour information documented on the FileEOF doc page."


I don't think its FileEOF that's at fault, WriteInteger writes 4 bytes and a null terminator, if you open the generated file in NotePad++ and remove the last null then FileEOF will work as expected, its WriteInteger that needs clarification about adding the null terminator.

EDIT: In fact all the Write* functions add a null, and string functions add a newline, all after the content so there will always be to much data in the file, either an extra null or newline, something to bear in mind when using such functions
Back to top
Profile PM
hendron
8
Years of Service
User Offline
Joined: 20th Dec 2015
Location:
Posted: 23rd Jun 2017 04:25
Link
Quote: "if you open the generated file in NotePad++ and remove the last null then FileEOF will work as expected, its WriteInteger that needs clarification about adding the null terminator."


I think that's just notepad++ displaying the final byte as null because it's 0 (which I believe is the same thing as a null terminator anyway). If you remove it in n++ and open the file in a hex editor, you can see that it's simply removed the last byte from the file, so that the final integer is represented by only 3 bytes. I'm guessing FileEOF will return true after reading the last integer in this case because it's overshot the file size by one byte.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-04-24 08:25:47
Your offset time is: 2024-04-24 08:25:47