Error 104 in TP 6.0 
Author Message
 Error 104 in TP 6.0

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?

Thanks,
HowarD



Wed, 18 Jun 1902 08:00:00 GMT  
 Error 104 in TP 6.0

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


Quote:
>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?

>Thanks,
>HowarD

Herbert Gintis
Department of Economics           Phone: 413-586-7756
University of Massachusetts       Fax:   413-586-6014
Amherst, MA 01003



Wed, 18 Jun 1902 08:00:00 GMT  
 Error 104 in TP 6.0



Quote:
>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?

Hello HowarD,

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

--
I have moved:

http://www.*-*-*.com/ ~rdonais/index.html
ftp://users.southeast.net/~rdonais/00index.txt



Wed, 18 Jun 1902 08:00:00 GMT  
 Error 104 in TP 6.0

Quote:
> 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.

   It's probably because he has Range Checking turned OFF (generally a
mistake, IMO), and his code stores file data over/on top of other
program data - some of which is his file variable/control table.  Most
likely, he's overrunning his array declaration - which Range Checking
would catch - and it's just a data/logic bug.
Quote:

> 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.
>                                              ^^^^^ Heap?

   I agree with the pointer array idea, but I also suggest he evaluate
the need for full 255 character strings in he array - it's seldom needed
for most applications (and Text files), so he should more carefully
define his data types (and turn of Range Checking, as well...).

Quote:
> >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)) and (X <= array_limit) do

.........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Quote:
> >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?

   See above...


Wed, 18 Jun 1902 08:00:00 GMT  
 Error 104 in TP 6.0

Quote:

> 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


> >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?I'm not so sure that Range Checking has anything to do with this.  I'm

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

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.

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



Wed, 18 Jun 1902 08:00:00 GMT  
 Error 104 in TP 6.0



 >
 > >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!

___ Blue Wave/QWK v2.20



Wed, 18 Jun 1902 08:00:00 GMT  
 Error 104 in TP 6.0

Quote:

> [snippage]
>  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.

Two points:  First, yes, it's certainly possible.  The only thing that
determines the length of a line is where a CR/LF (or other applicable
line terminator) occurs.  Second, no reading a longer line doesn't cause
an error.  Lines longer than 255 characters are truncated.

Quote:
> [...]
>  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!

Methinks Herb has been a little too much C programming.  It rots the
brain, ya know.  ;-)

Quote:
>  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.

True.  One possibility is to blockread() large amounts of data, then
grab bits from the large buffer.  Of course, if you only grab a byte at
a time via a procedure or function, you still lose a bit in overhead, so
you'd have to do some planning on how to accomplish the customized I/O.

Quote:
> [snipped rest]


--
Scott Earnest                      | _,-""-_,-""-_,-""-_,-""-_,-""-_,-"
|

|

|


Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Interbase 4 Script Error SQLCODE 104 Token unknown

2. I/O error 104 while parsing text file

3. TP 6.0 Source -> TP 7.0 Error

4. Question: Backward compatibility TP 7.0 & TP 6.0

5. Q: Incompatibilities between TP 6.0 and TP 7.0

6. How to get simple graphics in TP 6.0 ??

7. TCP/IP with DOS and TP 6.0 ?

8. TP 6.0 Sound

9. TP 6.0 TPU to 7.0 without original source?

10. TP 6.0 Manual/Help File

11. trig1.zip TP 6.0 trigonometry and math functions TPU, S.O'Malley

 

 
Powered by phpBB® Forum Software