I have experienced this on some accasions lately, and I'm stumped as to how to fix it.
The company I work with produces some HR software. one feature of this SFW is the ability to import payroll files into the system. These are standard Text files with each line marked as to what it is. An example of this file would be:
[ORg name deleted for security]
Now when the system reads this file (which can and usually does contain multiple .BEGIN and .END lines, as well as sometimes having multiple .BEGINDEPOSTS, .BEGINORGANIZATION, .ENDDEPOSITS, and .ENDORGANIZATION lines), it loops through based on a readln and the EOF() call. Fine right? However, when a customer called stating that their import was locking up and there had been absolutly no code changes, I grabbed their file and examined it. Odd thing I noticed, NO ^Z AT THE END OF THE FILE! Here's a debug output of the bottom of the file:
0FA7:01A0 5A 41 54 49 4F 4E 0D 0A-0D 0A 0E 8B 87 2E 4B A3 ZATION........K.
Notice the conspicous lack of a 1A after the end of the ZATION? When using this file, the system locks up. On a whim, I used debug to reaplce the 0E with a 1A (end of file/Ctl-Z). Result: System behaves perfectly.
So my question is: Is there a way I can force delphi to recognise the end of a file? Obviously windows recognised it because if I pull the file into a program like EDIT.COM, it reads the expected portion and thats it. But if I make changes to the file and re-save it back, still no EOF mark. So Obviously Windows is using some other method to check for the end of a file. How can I replicate that behavior in my code?