I have seen TextPad behave this way before when the file contained a NUL (0) char. My recollection is that TextPad popped up an error dialog box telling me why it was objecting. Nothing like this happened this time.
The problem gets weirder. I tried the exact same procedure described above with Notepad, and it behaved exactly the same. I tried the same procedure with WordPad, and it crashed; I have saved the Dr Watson log file. Has assembly language stack traces. Let me know if you want it posted. Finally, I tried the procedure with Word 2007, and it worked perfectly. Indeed, opening up both text files in TextPad later on and doing file compare (did not check to ignore anything) found identical contents.
I also analyzed the file with a Java program to confirm that every byte is US-ASCII. The code looks like this:
Code: Select all
for (int i = 0; i < bytes.length; i++) {
byte b = bytes[i];
if (b == 0) {
throw new RuntimeException("i = " + i + " is b = \"" + b + "\" which is a NUL byte");
}
if (b > 127) {
throw new RuntimeException("i = " + i + " is b = \"" + b + "\" (unicode = " + String.valueOf((int) b) + ") which is > 127");
}
if (b < 0) {
throw new RuntimeException("i = " + i + " is b = \"" + b + "\" (unicode = " + String.valueOf((int) b) + ") which is < 0");
}
}
Anybody seen this before, or is it a TextPad (or maybe Windows) bug?