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.