Why Does Last Line of VB6 Text File Being Read/Written to Another File Print Only Partially?
I am creating several text folders programmatically using VB6, and then concatenating them all together into a single file.
I write text to the files using
Print #lngFileHandle, Text
so there should be a CR/LF even after the very last line of text in each file.
Then I append all these "subfiles" together into another text file that was opened this way:
Open strFileName For Append As #lngFileHandle
Strangely, my final resulting file looks good EXCEPT that the very last line of the last file being appended is only partially there.
The last few lines look like this in the file I'm reading FROM:
`<Name>` Referral for Service Home Delivered Meals`</Name>`
`<Name>` Referral for Service Adult Day Care/Health`</Name>`
`<Name>` Referral for Service Congregate Meals`</Name>`
but after being read in from that file and output to the final file, they look like this:
`<Name>` Referral for Service Home Delivered Meals`</Name>`
`<Name>` Referral for Service Adult Day Care/Health`</Name>`
`<Name>` Referral for Service Congr
The code I'm using to read in this particular "subfile" and output it to the final file is:
With mobjNewEntriesLog
Do While Not .IsEOF
strOutput = .ReadLine
mobjMainLog.PrintLine strOutput
Loop
End With
开发者_开发问答
The .IsEOF function is as follows:
Public Function IsEOF() As Boolean
If blnOpened Then
IsEOF = EOF(lngFileHandle)
Else
IsEOF = True
End If
End Function
It would make more sense to me if I wasn't getting the last line at ALL, but getting just PART of it?--I don't get that.
Anybody see anything that would make the last line only print partially to the final file?
TIA.
Ensure you are closing your file as this may be required to flush out any data that is pending to be written.
VB6 file numbers are not file handles, so don't call them that. They are indexes into a file descriptor table in the runtime where the actual handle, mode, buffer length, buffer, ponters, etc. are stored.
The Close
statement is not synchronous, but a "lazy close" that may not have flushed all data and updated the EOF pointer of the file by the time you turn around and try to read it again. This behavior is intentional as far as I can determine, perhaps for performance reasons.
A Reset
statement can be used to force all open files closed, and it is synchronous. This isn't always practical, however it may be fine in your case. Easy enough to try: add a Reset before you re-open any of your files to concatenate them.
精彩评论