Detecting End-of-File using READLINE command

[Brian K. White]

----- Original Message ----- 
From: John Hemmer
To: filePro mailing list
Sent: Monday, September 13, 2004 12:08 PM
Subject: Detecting End-of-File using READLINE command


When using the READLINE command to read sequential records
e.g.

    bytes=READLINE(handle,destination,length)

When a line consists of just a newline character, the number of
bytes read and returned in "bytes" may be zero. However, there
could be many records that follow this line.

How can I detect the EOF, End-of-File?  Is a negative number
of bytes returned?

None of the Documentation I have, STN Manual, Online FilePro
help, etc,  answers these questions.

TIAA

John

-----------
starting here is brian speaking....  (html vs text quote problem)
(do you really want to be making it hard for people to help you, for free no
less?)

What I do is immediately after opening a file I seek to the end and store
the line number
then seek back to the beginning
then proceed with whatever reading I want to do
and immediately after each read I compare the current line number against
the stored ending line number.

Sounds like a lot of work but it's only 3 lines, maybe 2 depending:

1) added just after the open command:
ø If: ' find end-of-file           return to start
Then: pm_y = SEEK(pm_ho,"0","2") ; pm_x = SEEK(pm_ho,"0","0")

2) inserted after the readline, inside the loop that reads through the file:
ø If:                                         ' get current position
Then: pm_x = SEEK(pm_ho,"0","1")

3) inserted inside the same loop but after processing of the current lines
data:
ø If: pm_x lt pm_y                            ' loop if not eof
Then: goto reado


Depending on the particulars of your line data processing code, you could
probably combine the 2nd and 3rd lines into one, and put it after processing
the current line but inside the loop.

ø If: SEEK(pm_ho,"0","1") lt pm_y                            ' loop if not
eof
Then: goto reado

If the code that processes a line of data has to branch around a lot and
might not always return to the same place to read the next line, then
keeping 2) and 3) seperate like above works,


Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani