String PRB In Framework

  • Thread starter Thread starter MD Cobb
  • Start date Start date
M

MD Cobb

Is this problem only in VB.NET 2003 or in the actual
framework? Just to backtrack the length is updated (data
updated) but the value is always returned as null string
when the first character is null.

Private Sub Form1_Load(ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles MyBase.Load
MsgBox("After Get String Value Is: " & GetString
())
TextBox1.Text = GetString()
End Sub

Public Function GetString() As String
Dim newChar As Char
Dim str As String

str += newChar

str += "4"

MsgBox(str)
MsgBox(str.Length)
Debug.WriteLine(str)

Return str
End Function
 
MD Cobb,
The problem is in your code! :-)
Dim newChar As Char

You did not initialize the char variable, it will be Char.MinValue, in other
words ChrW(0), commonly used as a string terminator!
Dim str As String

You did not initialize the string variable, being a reference type it will
be Nothing.
str += newChar

The framework allows this and you get a string that has ChrW(0) in it. An
empty string (String.Empty) is used in place of Nothing for the str
variable, the ChrW(0) is still used for the newChar!
str += "4"

You get a string with 2 characters: ChrW(0) & "4"
MsgBox(str)

MsgBox, which calls the Win32 MessageBox API, honors ChrW(0) as a string
terminator.
MsgBox(str.Length)
Confirms the string has 2 characters in it!
Debug.WriteLine(str)

Debug.WriteLine honors ChrW(0) as a string terminator.

TextBox1.Text = GetString()


TextBox1.Text honors ChrW(0) as a string terminator.

Hope this helps
Jay
 
MC,
The value is returned incorrectly
What value is returned in correctly? The original string that had the
ChrW(0) in it?
I guess I would think that
appending a ChrW(0) would result in the the appended value
(Chr0) to be ignored by the string object.
There are cases where you need a ChrW(0) in the string, especially when you
are calling Win32 APIs and external components (TCP/IP, COMM ports & that
sort of thing). Remember ChrW(0) is still a valid character! Its just that
some of the Win32 stuff treat it as a terminator, some Win32 treat a single
ChrW(0) as a separator & double ChrW(0) as the terminator.
The value is returned
incorrectly and the only way to fix it is to make sure
that none of the char values are equal to ChrW(0) before
being appended to the string.
I hope you are ensuring your variables are initialized as oppose to checking
for ChrW(0) before each append. Consider using a String variable instead of
Char variable. Yes its 'heavier' in terms of memory, but it 'appends' closer
to how you are thinking.

Depending on the process, I would consider simply appending the ChrW(0) to
the StringBuilder, then 'remove' all of the ChrW(0) at the end of the
process. Either with the StringBuilder.Replace function or a For loop &
StringBuilder.Remove.

Hope this helps
Jay
 
Jay,

That explains it! Thanks.

MC
-----Original Message-----
MC,
What value is returned in correctly? The original string that had the
ChrW(0) in it?

There are cases where you need a ChrW(0) in the string, especially when you
are calling Win32 APIs and external components (TCP/IP, COMM ports & that
sort of thing). Remember ChrW(0) is still a valid character! Its just that
some of the Win32 stuff treat it as a terminator, some Win32 treat a single
ChrW(0) as a separator & double ChrW(0) as the terminator.

I hope you are ensuring your variables are initialized as oppose to checking
for ChrW(0) before each append. Consider using a String variable instead of
Char variable. Yes its 'heavier' in terms of memory, but it 'appends' closer
to how you are thinking.

Depending on the process, I would consider simply appending the ChrW(0) to
the StringBuilder, then 'remove' all of the ChrW(0) at the end of the
process. Either with the StringBuilder.Replace function or a For loop &
StringBuilder.Remove.

Hope this helps
Jay




.
 
Back
Top