|
I have some legacy VB6 code which im converting over to C#, and it seems that strings were implemented very differently in old VB than in the Framework. I get vastly different results from the ported code than I do from an app written in VB and I was wondering if anyone could put their finger on the reason why?
here is the old VB code (pstrResponse is the input to the method):
For i = 1 To Len(pstrResponse)
j = Asc(Mid(pstrResponse, i, 1))
If j > 127 Then
j = j - 128
Mid(pstrResponse, i, 1) = Chr(j)
End If
Next i
Here is my ported C# (input is the input):
char[] charArray = input.ToCharArray();
int bit;
for (int i = 0; i < charArray.Length; i++)
{
bit = (int)charArray[i];
if (bit > 127)
{
bit -= 128;
charArray[i] = (char)bit;
}
}
return new string(charArray);
As you can see, simple code & easy to port but very different results. Any ideas people?
|
|
|
|
|
.NET stores string in Unicode not Ascii and a char is 2 bytes not one I think? Which would mean the -=128 could have a different value in an integer data type?
I don't really know I am just speculating.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Which would mean the -=128 could have a different value in an integer data type
Any idea what it could be?
|
|
|
|
|
Maybe, Asc(Mid(pstrResponse, i, 1)) != (int)characters[i];
Try using the System.Text.AsciiEncoder to change the string by ascii bytes only first and see what happens?
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
Thanks for the pointers. With your help ive managed to solve the problem, but strangly enough I thought id need to convert my input to ASCII using ASCIIEncoding.GetBytes . In actual fact I had to use DefaultEncoding.GetBytes to get the result I was expecting.
here's the working code now:
byte[] byteArray = Encoding.Default.GetBytes(input);
StringBuilder sb = new StringBuilder(byteArray.Length);
byte bit;
for (int i = 0; i < byteArray.Length; i++)
{
bit = (byte)byteArray[i];
if (bit > 127)
{
bit -= 128;
}
sb.Append((char)bit);
}
return sb.ToString();
Thanks again for your help.
|
|
|
|
|
Apparently this still exists in the Microsoft.VisualBasic namespace.
This is the Asc function after being run through reflector - it seems to work OK.
public static int Asc(char theChar)
{
int num;
int num2 = Convert.ToInt32(theChar);
if (num2 < 0x80)
{
return num2;
}
try
{
byte[] buffer;
Encoding fileIOEncoding = Encoding.Default;
char[] chars = new char[] { theChar };
if (fileIOEncoding.IsSingleByte)
{
buffer = new byte[1];
int num3 = fileIOEncoding.GetBytes(chars, 0, 1, buffer,
0);
return buffer[0];
}
buffer = new byte[2];
if (fileIOEncoding.GetBytes(chars, 0, 1, buffer, 0) == 1)
{
return buffer[0];
}
if (BitConverter.IsLittleEndian)
{
byte num4 = buffer[0];
buffer[0] = buffer[1];
buffer[1] = num4;
}
num = BitConverter.ToInt16(buffer, 0);
}
catch (Exception exception)
{
throw exception;
}
return num;
}
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
Yeah, I saw that but I was attempting to avoid the use of nasty VB namespaces
|
|
|
|
|
J4amieC wrote: nasty VB
If you use the code above you don't need to - it's just that function converted to C#
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
J4amieC wrote: As you can see, simple code & easy to port but very different results
No, I can't see; what are the results?
Provided you don't care about Unicode, you could use:
System.Text.Encoding.ASCII.GetBytes()
and
System.Text.Encoding.ASCII.GetString()
You could also access the characters in an unsafe context much like your VB code. Something like:
private unsafe static void
ASCIIize
(
string Subject
)
{
fixed ( char* subject = Subject )
{
int* length = (int*) subject - 1 ;
int index = 0 ;
while ( index < *length )
{
*(subject + index) &= (char) 0x7F ;
index++ ;
}
}
return ;
}
(Though I haven't tested this with the problematic characters.)
|
|
|
|
|
PIEBALDconsult wrote: No, I can't see; what are the results?
The results are cryptic, horrible and mostly non-printable characters which is why I didnt post them. I meant the code was easy enough to port on the face of it.
|
|
|
|