Hello all,
I am having a problem with error 104.  I have a file that I am trying to
read into an array.  Partial code follows:
while not eof(file_name) do
begin
     readln(file_name,filedupe[x]);
     inc(x);
end;
The code works great until x equals 255.  At that point is when I get
the error "File not open for input".  X is declared as integer.  I don't
understand what is causing the file to close after x gets to this value.  
Any ideas or suggestions?

Your array has a maximum size of 64k. Each string has size 255 and so
you can have a maximum of 255 of them. I don't know why you get the
error you do, however.

The way around this is to declare the array to be an array of pointers
to string, and then leave the strings on the stack.

Herbert Gintis

There are a number of things that could at fault.  Have you
looked at the line where the error occurred?  Have you tried to
identify the problem with the de{*filter*}?  

It might help you and others learning on their own if we go
through a short debug session.  I assume you are using the TP/BP
7.0 IDE.  If not, then you will have to translate the following
for your setup.

Select "Search|Find Error" from the menu and enter the address
of the runtime error.  This should be on the Readln-statement.
You wouldn't normally need to do this step since you already
know where the error is occurring, but I thought you could use
the experience.

Place a breakpoint on this line. (Ctrl+F8)

With the above line highlighted, select "Debug|Breakpoint" and
click the Edit button.  

Enter  x := 253 in the "condition" field.  Or if you prefer you
can enter 253 in the "Pass" field.  But you've identified the
error w/ x > 255, so I would break on a value of "X" that occurs
just before the error.

HINT: If running with an older version that doesn't support
conditional breakpoints, add the following two lines just before
the breakpoint and replace the breakpoint as indicated.

    If x = 253 Then
       x = x;         { <--<< set breakpoint here! }

Setup a watch window to monitor the file variable.  With the
cursor on your file variable, press Ctrl+F7, then accept the
watch entry.

When the program first starts, the watch window will display
"FileVar:(Closed)".  After the Assign statement, it will be
"FileVar: (Closed, 'FileSpec')".  After the Reset statement it
will display "FileVar: (Input: 'FileSpec')".  If you wish you
may press F8 to step through your program to verify this for
yourself.

Press F9 to run the program.  When the breakpoint occurs, press
F8 to step through your program, one line at a time.  Watch the
file variable to see when it becomes something other than
"Input".  If the file has already changed, then stop the program
(Ctrl+F2) and set the condition lower.  And try again.

WHen you see the state of the file change from "Input", analyse
what happened.  Examine other variables (Ctrl+F4) if  necessary.
I got you this far, now its up to you to make sense of what you
see.  Are you writhing outside the range of the array?  Actually
you should have range checking on to catch this.  Are you doing
something recursively causing a stack overflow?  Of course you
should have stack checking on to catch this.

Have a happy holiday.  Hope you find your problem w/o too much
trouble.

    ...red

By the way, a more space effiecient way to store the strings would be to
just declare a large array (64k) of byte and read the text into it.  
That's a fair sized text file.  The proposed pointers would be NEAR, so
that's about 512 bytes your saving by just storing the text in one big
buffer instead of individual stings (actually more, because remember
that Pascal strings are not only null-terminating, but also store their
length as the first byte).  So that's 512 + 256 = 768 more bytes saved.
 If you just copy each character as you read it from the file to the
buffer, then you'll also copy the end of line characters, so that when
you spit the buffer back out again, the structure will remain the same,
and you'll have a verbatim copy of the text file.  There's no need to
save each line as a string so you can keep the text on each line the
same.

 >
 > >Hello all,
 > >I am having a problem with error 104.  I have a file that I am trying to
 > >read into an array.  Partial code follows:
 > >while not eof(file_name) do
 > >begin
 > >     readln(file_name,filedupe[x]);
 > >     inc(x);
 > >end;
 > >The code works great until x equals 255.  At that point is when I get
 > >the error "File not open for input".  X is declared as integer.  I don't
 > >understand what is causing the file to close after x gets to this value.
 > >Any ideas or suggestions?

 >
 > Your array has a maximum size of 64k. Each string has size 255 and so
 > you can have a maximum of 255 of them. I don't know why you get the
 > error you do, however.
 >
 > The way around this is to declare the array to be an array of pointers
 > to string, and then leave the strings on the stack.
 >
 > Herbert Gintis
 >

 In> I'm not so sure that Range Checking has anything to
 In> do with this.  I'm  just thinking that it's suspicious that you get an
 In> error just as  capacity of the file buffer is reached...it might have
 In> to do with  inappropriate use of the file I/O functions.  It might be a
 In> long shot,  by try and flush the file buffer every 254 iterations of
 In> the loop w/ and  if statement in there.  The other thing is that,
 In> depending on what  you're reading, there might very well be lines of
 In> text longer than 255  characters per line; and that would cause that
 In> error too I think.

I don't think that's possible if this is a text file.

 In> By the way, a more space effiecient way to store the strings would be
 In> to  just declare a large array (64k) of byte and read the text into it.
 In> That's a fair sized text file.  The proposed pointers would be NEAR,
 In> so  that's about 512 bytes your saving by just storing the text in one
 In> big  buffer instead of individual stings (actually more, because
 In> remember  that pascal strings are not only null-terminating, but also
 In> store their  length as the first byte).  So that's 512 + 256 = 768 more

Uh.. What??? Pascal strings are NOT null terminated!

 In> bytes saved.  If you just copy each character as you read it from the
 In> file to the  buffer, then you'll also copy the end of line characters,
 In> so that when  you spit the buffer back out again, the structure will
 In> remain the same,  and you'll have a verbatim copy of the text file.

Reading a byte at a time is also very slow and inefficient.

 In> There's no need to  save each line as a string so you can keep the text
 In> on each line the  same.

 In> You'll eventually run out of memory this way to.  I haven't
 In> programmed in Pascal for awhile (switched to C), but there should be a
 In> way with Borland compilers to switch the memory model to large or
 In> huge,  so that you arrays can extend across more than one segment (i.e.
 > 64k).

Maybe you should stop trying to help where you aren't sure of what you're
talking about then, and stick to relearning Pascal for a while. Pascal
doesn't offer different memory models the way C does. There are a number of
work-arounds for using data structures larger than 64k, but with the little
bit of code provided for the original posters problem I don't see how this
is even relevant.

  /-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-\

  %               http://www.*-*-*.com/ ~kforwood/              $
  $         For what purpose is life, if one cannot live freely?         %
  \-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-/
        WARNING: Flames and adverti{*filter*}ts sent to my email address
              may result in 20 gigabytes of garbage returned!