Reading chr(26)

Hi.
I have a problem when trying to read a file containing the character 26
when trying to read this caracter, my position pointer det incremented by what look like a random number(skipping some bytes)
is there a way to read the ascii char 26 returning a variable containing chr(26) instead of substituing bytes.

example : creating all ascii char:



and then trying to read:


caractCode take values from 0 to 25 and then from 153 to 255
then the loop crash as it is trying to read past EOF

thx

Writing actual control codes and reading them back can be iffy, as you've discovered. My guess is that when you get to ctrl-z which I believe is decimal 27, which is also the code for ESC, that code is seen by VB and it causes VB to do something.

Change to binary the type of access

Open "source.txt" For Binary As #1

Thx but I've already tryed and it wont work either. I get the same result.

is there a way to get/set my File pointer position? I can alway skip misbehaving bytes

Maybe if you explained what you're trying to accomplish it would help.

Information on VB6 file handling is here http://msdn.microsoft.com/library/e...eProcessing.asp

i'm trying to make a Vigenère cypher application using the ASCII table.

Oops, I have no idea what that is, unless it's a new kind of salad dressing or something

Anyway, read over the information on VB and files, I'm sure you'll find the answers there.

why not using the ADODB.Stream object? as far as I know, VB has this component
and I'm using it in classic ASP to handle binary files just fine.

Actually, ctrl-z is ASCII 26, not 27. You're correct in that ESC is ASCII 27, but that's not the issue here. In DOS, there were two kinds of file I/O (1. ASCII file and 2. Binary File), probably as a CP/M heritage. When performing file I/O in ASCII mode, the OS actually interprets certain control characters before passing them on to the program, whereas in binary mode, the data is passed through uninspected. As it happens, ASCII 26 is considered the EOF (End of File Character) and so, when the OS is reading the file in ASCII I/O mode and sees the character, it interprets it as end of file and stops reading any more, even if there is more data to read from the file. In binary I/O mode, it simply reads the data and passes it on to the program.

Contrast this with UNIX where file I/O is always binary. Unfortunately, this borked DOS behavior was also ported into Windows in the name of backward compatibility. This problem exhibits itself, even if you're not using VB for programming (C, C++, perl, python, ruby, Delphi etc.), since it is OS behavior rather than a function of the language. All these languages have a way to open a file in BINARY or ASCII mode (default is ASCII, due to DOS).
http://msdn.microsoft.com/library/d...l/vastmOpen.asp
http://msdn.microsoft.com/library/d.../vastmopenx.asp <-- Contains example for Binary
http://msdn.microsoft.com/library/d...l/vastmopen.asp