Visual Basic 6: Input Past End of File ... But it isn't

Factual Questions
1

I’ve programmed with Visual Basic for, gah, many many years. Since VB for DOS. And with various flavors of Basic going all the way back to Commodore 64. I use VB professionally, and have for ten years or so. I’ve never seen anything like this.

Right now, I’m working with some legacy code.

Ideally, I would post the actual code, but I can’t do that for several reasons, including the fact that it is proprietary (and doesn’t belong to me), plus it is very long. But I can give you a snippet. Unfortunately, the problem is reproducible only with a certain data set and with a certain error condition. I’ll try to answer whatever questions you may have.

Here’s an overview: As errors are trapped in the program, information about them, along with where they occured, when, and what values key variables had is written to a sequential file in a very standard way:



Open App.path & "\Errors.Log" For Append As FileNumber
    Print #FileNumber, Now & CR & LongMessage & CR & "----------------" & CR
Close FileNumber

(CR is vbCRLF & vbCRLF)

Now, there is a secret key combination that support staff can tell a user to hit, which will open the errors log. We also use it during development and testing. And here is the essential code for opening it. Again, very very simple and standard:



Open App.path & "\Errors.Log" For Input As FileNumber
    txtErrorReport.Text = StrConv(InputB(LOF(FileNumber), FileNumber), vbUnicode)
Close FileNumber

At this point, it might be important to know that none of this has ever been a problem until today. You open the error log, you read the errors, you close it, you go about your business. But today, VB gave the message “Input Past End of File” when the assignment was made to txtErrorReport.Text.

So, I put in a break-point, stopped the code at that assignment, and examined the particulars.

Filenumber = 1
LOF(Filenumber) = 1960

Printing out “InputB(1960, 1)” in debug window produced error. So I closed it and opened it again, printing only 1 byte. No problem. Using a sort of binary chop method, I went up and down and up and down, eventually settling on "InputB(1260, 1). That was the extent to which it would print. A difference of 700 bytes.

However…

That was indeed the whole file. Everything it printed out was the totality of the file. I opened Notepad to compare and make sure.

Then…

I saved it with Notepad. When I did, the problem cleared up! The file was 1960 bytes again, and printing out “InputB(1960, 1)” raised no error! Wha…!?

So, saving it with Notepad made a difference, and made it read to the real end of file (which matched the allegedly truncated file). That made me think that there was an end of file marker written to the file somehow from the particular data at that time.

But the place where the data cuts off is in the middle of a string representing a path, right between the “a” and “v” of the word “Braveheart”. Sure enough, from that “v” to the rest of the file, it is 700 bytes. There’s no end of file marker there.

Does anyone have any clue what this might be?

2

As a totally wild guess, perhaps your data is messed up and “Braveheart” contains a null byte or some control character after the “v”? It wouldn’t be obvious unless you examined the data with a binary editor. Notepad would probably eliminate any null bytes when saving.

3

That should be before the “v”. :smack:

4

Nothing to offer in the way of explanation beyond a suspicion of a one-time glitch. But I have to second friedo’s concern about Notepad. When I was still using Windows98, I used to use it and it does (or used to anyway) some character translations that you’d not be aware of if you didn’t already know it did them. I’ve found that vim displays all the non-standard characters I’ve thrown at it.

5

Are you possibly trying to open up a Unicode/UTF16/UTF32 file in a language that is not Unicode aware? I’m not sure if notepad supports Unicode but I’m guessing it saves as ASCII/UTF8 which would fix your problem. If you have the original file, try opening it up in a hex editor and checking if the NULL or EOF charecter appears right after the v.

PS: Why does your error log contain a Mel Gibson movie in it? :?

6

It’s part of a client’s username. I’ve verified that there are no null characters, and the problem is repeatable using the same dataset. […shrug…] I guess I’ll just redirect it to open Notepad with the errors file whenever that error occurs.

7

Could you post the hex of the 10 charecters around the v of both the working and non working version? Also, have you tried doing a diff on the 2 files?

8

There’s a chance you might have gotten a CHR(0) in the file. IIRC, that will function as an EOF marker, but it’s been a while and I stand to be corrected.

9

They’re both the same:

706C616365732042726176656865617274206765

10

According to a similar thread in the VB Explorer forums this may be caused by a file having more than one EOF character. It looks like the way around this is to open the file in Binary mode. Anyway here is a link to the thread:

http://p077.ezboard.com/fvisualbasicexplorerfilesfoldersdirectories.showMessage?topicID=2030.topic