File IO-I am defeated!

PeterD · Joined: 04 Oct 2007 Posts: 245

OK, I have what should be the simplest of code fragments that there
is. Open a file, read it, close:

50 If funFileExists(strPath) Then ' file is really there.
55 nFile = FreeFile
60 Open strPath For Input Lock Read As #nFile
61 nFileLength = LOF(nFile)
63 If nFileLength > 0 Then ' File has data in it...
70 strBuffer = Input(nFileLength, #nFile)
73 End If
80 Close #nFile
90 End If

Now, this is something that I'd teach in my Intro to Programming
class, and expect it to work 100% of the time. The file's contents are
text, there is nothing special about the file. Usually the file is
created by the program dynamically, occasionally it will be an
existing file.

I'm getting err.number = 70, err.description = "Input past end of
file" for some users! This has *got* to be something so obvious that I
can't see it, but what????

BTW, I have no hair left, and am willing to post a picture proving it!

Archived from group: microsoft>public>vb>general>discussion

PeterD · Joined: 04 Oct 2007 Posts: 245

On Wed, 27 Feb 2008 14:56:58 -0500, PeterD wrote:

>OK, I have what should be the simplest of code fragments that there
>is. Open a file, read it, close:
>
>
>50 If funFileExists(strPath) Then ' file is really there.
>55 nFile = FreeFile
>60 Open strPath For Input Lock Read As #nFile
>61 nFileLength = LOF(nFile)
>63 If nFileLength > 0 Then ' File has data in it...
>70 strBuffer = Input(nFileLength, #nFile)
>73 End If
>80 Close #nFile
>90 End If
>
>Now, this is something that I'd teach in my Intro to Programming
>class, and expect it to work 100% of the time. The file's contents are
>text, there is nothing special about the file. Usually the file is
>created by the program dynamically, occasionally it will be an
>existing file.
>
>I'm getting err.number = 70, err.description = "Input past end of
>file" for some users! This has *got* to be something so obvious that I
>can't see it, but what????
>
>BTW, I have no hair left, and am willing to post a picture proving it!

Make that err.number = 62, the line number is 70... (sorry)

Bob Butler · Joined: 04 Oct 2007 Posts: 1081

"PeterD" wrote in message @4ax.com...
> OK, I have what should be the simplest of code fragments that there
> is. Open a file, read it, close:
>
>
> 50 If funFileExists(strPath) Then ' file is really there.

and, apparently, is a lot of fun

> 55 nFile = FreeFile
> 60 Open strPath For Input Lock Read As #nFile
> 61 nFileLength = LOF(nFile)
> 63 If nFileLength > 0 Then ' File has data in it...
> 70 strBuffer = Input(nFileLength, #nFile)
> 73 End If
> 80 Close #nFile
> 90 End If
>
> Now, this is something that I'd teach in my Intro to Programming
> class, and expect it to work 100% of the time. The file's contents are
> text, there is nothing special about the file. Usually the file is
> created by the program dynamically, occasionally it will be an
> existing file.
>
> I'm getting err.number = 70, err.description = "Input past end of
> file" for some users! This has *got* to be something so obvious that I
> can't see it, but what????
>
> BTW, I have no hair left, and am willing to post a picture proving it!

If the file contains a ^Z character it will be treated as EOF when read that
way.

Try opening it for Binary and using Get to read the contents

MP · Joined: 04 Oct 2007 Posts: 203

"PeterD" wrote in message @4ax.com...
> OK, I have what should be the simplest of code fragments that there
> is. Open a file, read it, close:
>
>
> 50 If funFileExists(strPath) Then ' file is really there.
> 55 nFile = FreeFile
> 60 Open strPath For Input Lock Read As #nFile
> 61 nFileLength = LOF(nFile)
> 63 If nFileLength > 0 Then ' File has data in it...
> 70 strBuffer = Input(nFileLength, #nFile)
> 73 End If
> 80 Close #nFile
> 90 End If
>
> Now, this is something that I'd teach in my Intro to Programming
> class, and expect it to work 100% of the time. The file's contents are
> text, there is nothing special about the file. Usually the file is
> created by the program dynamically, occasionally it will be an
> existing file.
>
> I'm getting err.number = 70, err.description = "Input past end of
> file" for some users! This has *got* to be something so obvious that I
> can't see it, but what????
>
> BTW, I have no hair left, and am willing to post a picture proving it!

I'm the first to admit I know nothing about anything but in some dim recess
of faulty memory...
wasn't there something about old old files having some kind of non-printing
eof marker
and newer ones didn't, but the presence or absence did something weird with
eof detection?
or something about unicode/ansi??/
mark

Lorin · Joined: 04 Oct 2007 Posts: 312

Maybe the file is still open from a previous attempt and failure.
Close the IDE and see if the problem goes way when tried again.

I would write the code as follows so any error would make sure the file was
closed.
Of course the code needs to run to completion and it cannot be stopped in
the IDE.

Private Function Something(strPath as string) as String
On Error GoTo SomethingErr
Dim ' all that stuff below
Dim nFile as Long
Dim nFileLength as Long
Dim strBuffer as String

50 If funFileExists(strPath) Then ' file is really there.
55 nFile = FreeFile
60 Open strPath For Input Lock Read As #nFile
61 nFileLength = LOF(nFile)
63 If nFileLength > 0 Then ' File has data in it...
70 strBuffer = Input(nFileLength, #nFile)
73 End If
90 End If
Something = strBuffer ' return this

SomethingExit:
80 Close #nFile ' will always execute and does nothing if file is not
open
' i.e. some error occurs within the sub
without reaching the
' Open statement
Exit Sub

SomethingErr:
' do something else here like report the error
Debug.Print Err.Description
' since you are using line number you could also include
Debug.print Erl
' this will print the line number of a line
' that was last executed that had a line number in front of it
' i.e. subsequent executed line(s) with no numbers that
' error out will print that last line number
Resume SomethingExit ' now go close if already open

End Sub

"PeterD" wrote:

> OK, I have what should be the simplest of code fragments that there
> is. Open a file, read it, close:
>
>
> 50 If funFileExists(strPath) Then ' file is really there.
> 55 nFile = FreeFile
> 60 Open strPath For Input Lock Read As #nFile
> 61 nFileLength = LOF(nFile)
> 63 If nFileLength > 0 Then ' File has data in it...
> 70 strBuffer = Input(nFileLength, #nFile)
> 73 End If
> 80 Close #nFile
> 90 End If
>
> Now, this is something that I'd teach in my Intro to Programming
> class, and expect it to work 100% of the time. The file's contents are
> text, there is nothing special about the file. Usually the file is
> created by the program dynamically, occasionally it will be an
> existing file.
>
> I'm getting err.number = 70, err.description = "Input past end of
> file" for some users! This has *got* to be something so obvious that I
> can't see it, but what????
>
> BTW, I have no hair left, and am willing to post a picture proving it!
>

Mike Williams · Joined: 04 Oct 2007 Posts: 1309

"PeterD" wrote in message @4ax.com...

> Make that err.number = 62, the line number is 70... (sorry)

You're getting an "input past end of file" error. This is typical if you
open a file in Input mode (as you are doing) and using Input to retrieve the
data. The error will occur if any byte in the file has the value 26 (the EOF
character) and I think also if any byte has the value zero. You will almost
certaionly find that your file is not actually a standard text file at all,
and that it contains one or more of those bytes. Try opening it in binary
mode and using Get to retrive the data (which will work regardless of the
data bytes the file happens to contain). Here is a slight modification of
your own code which does exactly that and which then display the file bytes
in a ListBox (place a ListBox on your Form). Have a look through the
contents of the ListBox and you'll see exactly what the file contains. (If
the file is very large then post back and we'll show you how to load it all
and display only the buytes that may be gidving you the problem).

48 Dim b() As Byte
50 If funFileExists(strPath) Then ' file is really there.
55 nfile = FreeFile
60 Open strPath For Binary As #nfile
61 nFileLength = LOF(nfile)
63 If nFileLength > 0 Then ' File has data in it...
65 ReDim b(1 To nFileLength)
70 Get #nfile, 1, b()
73 End If
80 Close #nfile
82 For n = 1 To nFileLength
83 List1.AddItem Format(n) & vbTab & Format(b(n))
84 Next n
90 End If

Mike

Larry Serflaten · Joined: 04 Oct 2007 Posts: 2644

"PeterD" wrote
> OK, I have what should be the simplest of code fragments that there
> is. Open a file, read it, close:

> 60 Open strPath For Input Lock Read As #nFile
> 70 strBuffer = Input(nFileLength, #nFile)
> 80 Close #nFile
>
> Now, this is something that I'd teach in my Intro to Programming
> class, and expect it to work 100% of the time.

I would not expect that to work 100% of the time and am surprised
that you would. You've opened the file, and locked out other apps
from reading it, why? If some other app does that, your code here
will fail on the Open command and has no error handler to handle
that condition.

I would expect that you should plan to lock writing to the file while
you are trying to read the data. And, I would expect that there should
be an error handler in place in case you are locked out of the file by
some other process.

As others indicated, the file contents may be causing your problem.
Specifically the EOF character will cause this error (Chr(26)).

Dim s As String
Dim f As Long, i As Long
Const test = "D:\temp\file.txt"

s = "test"
f = FreeFile
Open test For Output As f
Print #f, s
Close

Open test For Input As f
s = Input(LOF(f), f) ' it works...
Close

Debug.Print s

Open test For Binary As f
Put #f, 2, CByte(26)
Close

Open test For Input As f
s = Input(LOF(f), f) ' it errors
Close

Bob O`Bob · Joined: 04 Oct 2007 Posts: 1456

PeterD wrote:
> OK, I have what should be the simplest of code fragments that there
> is. Open a file, read it, close:
>
>
> 50 If funFileExists(strPath) Then ' file is really there.
> 55 nFile = FreeFile
> 60 Open strPath For Input Lock Read As #nFile
> 61 nFileLength = LOF(nFile)
> 63 If nFileLength > 0 Then ' File has data in it...
> 70 strBuffer = Input(nFileLength, #nFile)
> 73 End If
> 80 Close #nFile
> 90 End If
>
> Now, this is something that I'd teach in my Intro to Programming
> class, and expect it to work 100% of the time. The file's contents are
> text, there is nothing special about the file. Usually the file is
> created by the program dynamically, occasionally it will be an
> existing file.
>
> I'm getting err.number = 70, err.description = "Input past end of
> file" for some users! This has *got* to be something so obvious that I
> can't see it, but what????
>
> BTW, I have no hair left, and am willing to post a picture proving it!

Interesting code. If the file is empty, you only have an empty string
to go on, so reading it anyway can do no harm. Here's what I use:

fh = FreeFile
Open sFn For Input Access Read Lock Write As fh
GetFile = Input$(LOF(fh), fh)
Close #fh

Doesn't really address the errors you're reporting, but I think Mike
has covered that. Binary data can contain "EOF" characters without
them having any such intrinsic meaning.

Bob
--

"Rick Rothstein \ · Joined: 04 Feb 2008 Posts: 37

> OK, I have what should be the simplest of code fragments that there
> is. Open a file, read it, close:
>
> 50 If funFileExists(strPath) Then ' file is really there.
> 55 nFile = FreeFile
> 60 Open strPath For Input Lock Read As #nFile
> 61 nFileLength = LOF(nFile)
> 63 If nFileLength > 0 Then ' File has data in it...
> 70 strBuffer = Input(nFileLength, #nFile)
> 73 End If
> 80 Close #nFile
> 90 End If
>
> Now, this is something that I'd teach in my Intro to Programming
> class, and expect it to work 100% of the time. The file's contents are
> text, there is nothing special about the file. Usually the file is
> created by the program dynamically, occasionally it will be an
> existing file.
>
> I'm getting err.number = 70, err.description = "Input past end of
> file" for some users! This has *got* to be something so obvious that I
> can't see it, but what????
>
> BTW, I have no hair left, and am willing to post a picture proving it!

This is the code I use to load an entire file all at once; it will not be
fooled by end of file markers...

Dim nFile As Long
Dim TotalFile As String
.......
....... >
.......
If funFileExists(strPath) Then
nFile = FreeFile
Open strPath For Binary As #nFile
TotalFile = Space(LOF(nFile))
Get #nFile, , TotalFile
Close #nFile
End If

Rick

Saga · Joined: 04 Oct 2007 Posts: 809

Interesting thread.

Saga
--

"PeterD" wrote in message @4ax.com...
> OK, I have what should be the simplest of code fragments that there
> is. Open a file, read it, close:
>
>
> 50 If funFileExists(strPath) Then ' file is really there.
> 55 nFile = FreeFile
> 60 Open strPath For Input Lock Read As #nFile
> 61 nFileLength = LOF(nFile)
> 63 If nFileLength > 0 Then ' File has data in it...
> 70 strBuffer = Input(nFileLength, #nFile)
> 73 End If
> 80 Close #nFile
> 90 End If
>
> Now, this is something that I'd teach in my Intro to Programming
> class, and expect it to work 100% of the time. The file's contents are
> text, there is nothing special about the file. Usually the file is
> created by the program dynamically, occasionally it will be an
> existing file.
>
> I'm getting err.number = 70, err.description = "Input past end of
> file" for some users! This has *got* to be something so obvious that I
> can't see it, but what????
>
> BTW, I have no hair left, and am willing to post a picture proving it!

Karl E. Peterson · Joined: 04 Oct 2007 Posts: 4836

Bob O`Bob wrote:
> fh = FreeFile
> Open sFn For Input Access Read Lock Write As fh
> GetFile = Input$(LOF(fh), fh)
> Close #fh
>
> Doesn't really address the errors you're reporting, but I think Mike
> has covered that. Binary data can contain "EOF" characters without
> them having any such intrinsic meaning.

And, as we all learned with VB4, binary shouldn't be read into Strings anymore,
either.
--
..NET: It's About Trust!
http://vfred.mvps.org

Karl E. Peterson · Joined: 04 Oct 2007 Posts: 4836

Rick Rothstein (MVP - VB) wrote:
> This is the code I use to load an entire file all at once; it will not be
> fooled by end of file markers...

Just to toss even more options out there (ie, pile on ), mine:

Public Function ReadFile(ByVal FileName As String) As String
Dim hFile As Long
On Error GoTo Hell
hFile = FreeFile
Open FileName For Binary As #hFile
ReadFile = Space$(LOF(hFile))
Get #hFile, , ReadFile
Close #hFile
Hell:
End Function

Private Function ReadFileB(ByVal FileName As String, Data() As Byte) As Boolean
Dim hFile As Long
On Error GoTo Hell
hFile = FreeFile
Open FileName For Binary As #hFile
ReDim Data(0 To LOF(hFile) - 1) As Byte
Get #hFile, , Data
Close #hFile
Hell:
ReadFileB = Not CBool(Err.Number)
End Function

--
..NET: It's About Trust!
http://vfred.mvps.org

PeterD · Joined: 04 Oct 2007 Posts: 245

On Wed, 27 Feb 2008 15:17:49 -0600, "Larry Serflaten"
wrote:

>
>"PeterD" wrote
>> OK, I have what should be the simplest of code fragments that there
>> is. Open a file, read it, close:
>
>
>> 60 Open strPath For Input Lock Read As #nFile
>> 70 strBuffer = Input(nFileLength, #nFile)
>> 80 Close #nFile
>>
>> Now, this is something that I'd teach in my Intro to Programming
>> class, and expect it to work 100% of the time.
>
>I would not expect that to work 100% of the time and am surprised
>that you would. You've opened the file, and locked out other apps
>from reading it, why?

I wasn't clear... This is a temporary work file that my application
creates. I know it is text (not binary) because that is what I write.
I would be astounded if another application was reading my file!

>If some other app does that, your code here
>will fail on the Open command and has no error handler to handle
>that condition.

There is an error handler just above the posted snippet.

>
>I would expect that you should plan to lock writing to the file while
>you are trying to read the data. And, I would expect that there should
>be an error handler in place in case you are locked out of the file by
>some other process.
>
>As others indicated, the file contents may be causing your problem.
>Specifically the EOF character will cause this error (Chr(26)).

That was a thought of mine, too...

>
>Dim s As String
>Dim f As Long, i As Long
>Const test = "D:\temp\file.txt"
>
> s = "test"
> f = FreeFile
> Open test For Output As f
> Print #f, s
> Close
>
> Open test For Input As f
> s = Input(LOF(f), f) ' it works...
> Close
>
> Debug.Print s
>
> Open test For Binary As f
> Put #f, 2, CByte(26)
> Close
>
> Open test For Input As f
> s = Input(LOF(f), f) ' it errors
> Close
>

christery · Joined: 11 Jan 2008 Posts: 71

On 27 Feb, 20:56, PeterD wrote:
> OK, I have what should be the simplest of code fragments that there
> is. Open a file, read it, close:
>
> 50 If funFileExists(strPath) Then ' file is really there.
> 55 nFile = FreeFile
> 60 Open strPath For Input Lock Read As #nFile
> 61 nFileLength = LOF(nFile)
> 63 If nFileLength > 0 Then ' File has data in it...
> 70 strBuffer = Input(nFileLength, #nFile)
> 73 End If
> 80 Close #nFile
> 90 End If
>
> Now, this is something that I'd teach in my Intro to Programming
> class, and expect it to work 100% of the time. The file's contents are
> text, there is nothing special about the file. Usually the file is
> created by the program dynamically, occasionally it will be an
> existing file.
>
> I'm getting err.number = 70, err.description = "Input past end of
> file" for some users! This has *got* to be something so obvious that I
> can't see it, but what????
>
> BTW, I have no hair left, and am willing to post a picture proving it!

Just of the top of my head, input: does it like CR/LF or just CR to
end... as in reading until it will get that, and then run out of
file... just a thought.. didnt try that out but you where asking for
obvious answers, and I provide a stupid one instead, probably wrong
too.

Thought it got EOF as in chr(3) or something but that reads as close
the file, otherwise called ETX in serial communications wich produces
strange results in some systems

The mysterious is however "some users"... so it works for some...
creating a file and then not closing it before reading, and the FAT
has another definition of the file than the physical environment.. (C
fflush comes to mind)

//CY