File content bugs

Awright, yo...
I'm having a bit of a problem. I've been experimenting with the B+ Demo lately, and I'm trying to create a program that can open any file, and display its contents in a text field. So for instance, a text file would display the same way it would in Notepad, but a sound file would be a load of "random" letters & symbols, as each byte was translated into a character.
My problem is this: every time I open a normal file, like a DOC, or a TXT, or even an HTM, it works fine; the contents display in the field. But when I try to load a bitmap image, all that shows up is "BM" followed by some kind of symbol, regardless of its size. I know that file size isn't the problem, because I've successfully opened text documents larger than the images I've tried.
A thought did cross my mind, however: any bitmap image is bound to contain at least one byte set to zero. Could this be making the text field "cut off" the contents prematurely? If so, any combat ideas?

I think that is it, some characters mark the end of a line, such as Chr$(0) or Chr$(13).
Maybe you could check the ascii value of the last character that is shown, or the one after it ?
An ascii table might help: http://www.asciitable.com/
Usually, to edit files of any type, a Hexeditor is used. It convertes all bytes into hex values. This looks nicely, because a value between 0-255 can be represented with two characters in hex. ($00-$FF) To maintain readability, after the hex value, between brackets, the ASCII character is shown.
So either use the ASCII values or find characters that can be used as a substitute, .. ADAM :D

in windows new next line = chr(13) + chr(10), but in linux it's just chr(13)

Try using textarea?

Use "ReadByte" instead of "ReadLine" when opening an non-text file.

After "ReadByte" check for valid character. Should be in range of ASCII 32-127, if not then it's probably not a printable character.

Thanks everyone, I think that helps. Andy_A, I did use ReadByte at one point, but it was far slower... Not that my computer's exactly top-range, however (HP Win98 w/ Celeron 300? 400? Mhz (not quite sure), 256 MB RAM, 16 MB GFX mem ( ! ).)

Or rather than use "readbyte", create a bank the same size as the file and read all the bytes into the file

yourfilehandle=readfile("filename.abc")
bank=createbank(filesize(yourfilehandle))
readbytes bank,yourfilehandle,0,banksize(bank)
closefile yourfilehandle
;then parse through the bytes in the bank and check the ASCII value of each byte in the bank rather than as it is read from the file.

The CPU is not the bottleneck, it's the disk access that makes "readbyte" so much slower.

I mentioned readbyte because it's the most straight forward to understand.

"Readbytes" (plural) is faster because you're reading in the whole file at once instead of one byte at a time. Matty mentions reading in the whole file, which is best for small files. If you have very large files you could read in 1024-4096 byte chunks (same size as a disk sector) instead of the whole file, as this would still be pretty fast.

Woah, never heard of ReadBytes! That's the problem with the B+ Demo, the command ref isn't available, and my computer doesn't have internet access, so I can't refer to the online ones as needed. Thanks for the tip, I'll try it!!!
Oh, BTW Andy_A, I know that CPUs normally aren't the cause of disk slowdowns, but in this case it isn't the access of the bytes that's the problem; any Blitz programs run in windowed mode on my PC go verrry slooow as it is; the hard drive itself is actually quite speedy!