Remove Spaces

A

ADO DOT NET

Centurion
Joined
Dec 20, 2006
Messages
160
Hi,
Is there a function in VB that get a string and removes the empty spaces only at left and right of the string?
I mean just remove the spaces at first and end of string?
Thanks:)
 
You can either use the .NET String methods "TrimEnd" and "TrimStart" or use the VB functions "RTrim" and "LTrim".
 
Would the string.Trim function suit your purposes?
Code: 
[Color=Blue]Dim[/Color] Trimmed [Color=Blue]As String [/Color]= ([Color=DarkRed]"    SPACES     "[/Color]).Trim() [Color=Green]'Trimmed = "SPACES"[/Color]
[Edit]Looks like David Anton beat me to the punch, but now I'm not sure whether you were looking to trim both the start and end at once, or only one or the other. Now we have all our bases covered, I guess.[/Edit]
 
But the behavior between Trim() as a method of a string and Trim() as a function inherited from VB language is different right?

Using the Trim() function requires the string to be pass as a parameter. marble_eater shows using the Trim() method of a string.

CMIIW.
 
That is correct. The VB function is available mainly for backwards compatability reasons. They both basically do the same thing, but the syntax is different. Also, I'm not sure whether or not they work exactly the same. You would have to look at the documentation. Trim() works the way it did in VB6. String.Trim() works the DotNet way. There may be a difference in what they consider whitespace. They may be the same, they may not be. I don't know.

Code: 
[Color=Blue]Dim[/Color] spaced [Color=Blue]As String [/Color]= [Color=DarkRed]"    spaced out    "[/Color]
[Color=Blue]Dim[/Color] unspaced1 [Color=Blue]As String [/Color]= Trim(spaced)
[Color=Green]' results in "spaced out"[/Color]
[Color=Blue]Dim[/Color] unspaced2 [Color=Blue]As String[/Color] = spaced.Trim()
[Color=Green]' also results in "spaced out"[/Color]
 
One main difference between the .NET methods and the VB methods is that the VB methods will attempt to avoid exceptions at all costs.
e.g., the following assigns an empty string to s2, but results in an exception when attempting to assign to s3 (excuse the variable names):
Dim s1 As String
Dim s2 As String = Trim(s1)
Dim s3 As String = s1.Trim()
 
I would say that that particular error is the consequence of the difference between an object oriented approach and a non-OOP approach.

I whipped up a quick app...
Code: 
[Color=Blue]Private Sub[/Color] Form1_Load([Color=Blue]ByVal [/Color]sender [Color=Blue]As [/Color]System.Object, [Color=Blue]ByVal [/Color]e [Color=Blue]As [/Color]System.EventArgs) [Color=Blue]Handles [/Color][Color=Blue]MyBase[/Color].Load
    [Color=Blue]For [/Color]i [Color=Blue]As Integer [/Color]= 0 [Color=Blue]To [/Color]255
        TextBox1.AppendText((Chr(i) + i.ToString() + Chr(i)).Trim() + Environment.NewLine)
        TextBox2.AppendText(Trim(Chr(i) + i.ToString() + Chr(i)) + Environment.NewLine)
[Color=Blue]    Next
End Sub[/Color]
It seems the DotNet String.Trim() function trims all whitespace, while the legacy Trim() function trims only spaces.
 
David Anton said:
One main difference between the .NET methods and the VB methods is that the VB methods will attempt to avoid exceptions at all costs.
e.g., the following assigns an empty string to s2, but results in an exception when attempting to assign to s3 (excuse the variable names):
Dim s1 As String
Dim s2 As String = Trim(s1)
Dim s3 As String = s1.Trim()
Click to expand...

Isn't the cause of the exception trying to access a method from a null object? s1 is null right?
 
VB "features"

amir100 said:
Isn't the cause of the exception trying to access a method from a null object? s1 is null right?
Click to expand...

Sure.

I know this is straying way off topic, but I think the fact that Microsoft has implemented so many of these legacy functions is one of the main detractors of VB.Net. Now we have 2 methods with similar or identical names which both behave differently. I really wish Microsoft had been strong enough to not pander to the whole backwards-compatibility crowd and actually forced people to learn how to program properly - a null reference is not the same as a null string. Most applications should be entirely rewritten when converting from VB6 to VB.Net, so the inclusion of these methods is a little unhelpful.

I know it sounds drastic, but I would seriously recommend any VB.Net programmers wishing to improve the quality of their code delete any references to Microsoft.VisualBasic, and start converting their code to using the standard framework classes.
 
Re: VB "features"

Well, now that we are off topic, it is easy to say that Microsoft should have had the cojones to do away with VB6 legacy functions, controls, and features that might be redundant or "encourage bad programming." It's a whole different story when you are trying to sell Visual Basic. For businesses, it is not acceptable to have to re-write entire applications. This "backwards compatability" sometimes brings porting programs into the realm of possibility.

I agree whole-heartedly with your recommendation to stay away from VisualBasic namespaces, but for pre-existing code there is a need for compatability and Microsoft had to try to fulfill this need in order to make the purchase more worthwhile for more customers.
 
Re: VB "features"

I'd agree with marble_eater regarding backward-compatibility. But it would be so much better if Microsoft would provide backward-compatibility using the Framework instead of simply creating a general Microsoft.VisualBasic namespace. That way converting VB6 code to .Net would be as easy as always without any traces of legacy codes left in the converted code. I think this is what MrPaul is trying to say.

The existence of Microsoft.VisualBasic is simply for backward-compatibility right? This wouldn't go with the concept of interoperability between .Net language. Considering I'm using two language in .Net (i.e. VB and C#), I always tried my best not to use any code from Microsoft.VisualBasic.
 
Re: VB "features"

amir100 said:
I'd agree with marble_eater regarding backward-compatibility. But it would be so much better if Microsoft would provide backward-compatibility using the Framework instead of simply creating a general Microsoft.VisualBasic namespace.
Click to expand...
That would require polluting the standard DotNet libraries with VB6 functions. I don't see any other way to get VB6 code to compile to DotNet. I think Microsoft put the legacy functions in the right place.

The existence of Microsoft.VisualBasic is simply for backward-compatibility right? This wouldn't go with the concept of interoperability between .Net language.
Click to expand...
Quite a common complaint. This is why we always tell new programmers to remove all references to Microsoft.VisualBasic and Microsoft.VisualBasic.Compatability. The biggest problem is that these don't come excluded in new projects by default and Microsoft does very little to encourage programmers to migrate new the "DotNet" method of doing things.
 
Back
Top