String.ASC and (int)

[skeamy]

Hi everybody,
Im currently converting an application from VB6 to C# which contains
logic to convert EBCDIC to ASCII and vice versa. I have a test app
which reads some previously stored EBCDIC from a text file and
converts it. I have finally got it all working (Encoding.DEFAULT was
the turning point when reading the file)

I am now trying to remove all references to the Microsoft.VisualBasic
and Compatibility namespaces and use the C# System namespace
equivilents (Purely for my own experience I am not starting a debate
about this). I have everything changed except a packed date routine
which uses Strings.ASC and uses the last char of the packed field to
indicate whether its a positive or negative number - I have isolated
the problem to a few lines of code and wonder if someone can explain
what is happening

char cTest = (char)(174);
MessageBox.Show(((int) cTest ).ToString()); // Returns 174 Works OK
MessageBox.Show(Strings.Asc(cTest).ToString()); // Returns 174 Works
OK
char cTest1 = (char)(338);
MessageBox.Show(((int) cTest1 ).ToString()); // Returns 338 Doesn't
work
MessageBox.Show(Strings.Asc(cTest1).ToString()); // Returns 140 Works
OK
char cTest2 = (char)(337);
MessageBox.Show(((int) cTest2 ).ToString()); // Returns 337 Doesn't
work
MessageBox.Show(Strings.Asc(cTest2).ToString());// Returns 111 Works
OK

I was led to believe that the VB6 function ASC() returned the
equivilent of (int) char in C# but Im missing something. Does anyone
know how String.ASC is achieving its (working) results?

Thanks
Please reply in this thread not to email

 

[Nicholas Paldino [.NET/C# MVP]]

When converting a character to an int, you shouldn't expect any change
to take place. An int can hold any value that a character can represent, so
the int will just be the same value as the character. When you see 337,
338, that is correct.

When you run the values of 337 and 338 through ASC in VB6, you get 51,
not the values you are getting, so the logic is definitely different from
..NET, which produces the results you are getting (I get the same when
running in .NET).

Basically, if you want to convert to a character and get those results,
you will have to reference Microsoft.VisualBasic.dll, and use the ASC
function. It has certain logic for endianness which the convert routines (I
used ASCIIEncoding, the Convert function) and a cast just don't do.

I don't believe this is an error though, as the cast and convert
functions (as well as the Encoder) works as advertised.

Hope this helps.

 

[Jay B. Harlow [MVP - Outlook]]

Skeamy,
(char) & (int) in C# deal with Unicode characters which are 16-bit.

Strings.Asc & Strings.Chr deal with Ansi characters (Encoding.Default) which
are 8-bit.

Strings.AscW & Strings.ChrW deal with Unicode characters.

To convert packed fields I would not bother with converting to Char. I would
work with the bytes (System.Byte) themselves & using shifting & anding I
would extact each half of the packed values...

Hope this helps
Jay