Removing VB6-isms, I'm stuck

[Peter Row]

Hi,

I am currently working on a VB.NET project that has been going for quite a
while.
In the past it has been developed with a lot of compatibility VB6 functions
and
constants, e.g Left(), LCase() and vbCr

Whilst not currently able to port to C# I am trying to remove usage of these
functions and constants.

However theres a bit of code that for simplicities sake says:

myString2 = Replace(myString, vbCr, vbCrLf)

So far I have converted this to:

myString2 = myString.Replace(vbCr, Environment.NewLine)

However what do I replace vbCr with?

Regards,
Peter

[Herfried K. Wagner [MVP]]

"Peter Row" <fuck.off@bastard_spammers.com> schrieb:

I am currently working on a VB.NET project that has been going for quite a
while.
In the past it has been developed with a lot of compatibility VB6
functions and
constants, e.g Left(), LCase() and vbCr
These methods are /not/ part of the compatibility library.
myString2 = myString.Replace(vbCr, Environment.NewLine)

However what do I replace vbCr with?

I prefer 'ControlChars.Cr', which is a VB.NET feature.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Terry Olsen]

Are the VB6 string functions going away soon? I still find myself using
them because vbCr is much shorter and easier then ControlChars.Cr.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uu**************@tk2msftngp13.phx.gbl...

"Peter Row" <fuck.off@bastard_spammers.com> schrieb:

I am currently working on a VB.NET project that has been going for quite
a while.
In the past it has been developed with a lot of compatibility VB6
functions and
constants, e.g Left(), LCase() and vbCr

These methods are /not/ part of the compatibility library.

myString2 = myString.Replace(vbCr, Environment.NewLine)

However what do I replace vbCr with?

I prefer 'ControlChars.Cr', which is a VB.NET feature.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Larry Lard]

Terry Olsen wrote:

Are the VB6 string functions going away soon? I still find myself using them because vbCr is much shorter and easier then ControlChars.Cr.

Do an Imports Microsoft.VisualBasic.ControlChars and you can use just
Cr, which is even shorter! :)

--
Larry Lard
Replies to group please

[Peter Row]

Hi,

Okay okay, bad wording.
What I mean is that functions like Left() and LCase() etc...
only exist to make old VB6-ers more comfortable.

In a proper .NET app you shouldn't use them because all they
are is wrappers around .NET CLR stuff, i.e. String.ToLower()

Why make multiple calls that can be done with 1?

I'll checkout the ControlChars.Cr but I don't really want
to use anything that is in a VisualBasic Namespace.

Is there not an equivalent of vbCr that is in the standard
System namespaces?

Bye,
Peter
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uu**************@tk2msftngp13.phx.gbl...

"Peter Row" <fuck.off@bastard_spammers.com> schrieb:

I am currently working on a VB.NET project that has been going for quite
a while.
In the past it has been developed with a lot of compatibility VB6
functions and
constants, e.g Left(), LCase() and vbCr

These methods are /not/ part of the compatibility library.

myString2 = myString.Replace(vbCr, Environment.NewLine)

However what do I replace vbCr with?

I prefer 'ControlChars.Cr', which is a VB.NET feature.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Peter Row]

Hi,

vbCr isn't a string function it's a constant.

I don't think things like that and Left() etc... are going away
anytime soon, but I just don't want to use them because
they are wrappers around inbuilt .NET functionality and only
exist to try and persuade stubborn people to leave VB6
behind once and for all.

If I had the choice I'd migrate the project I'm on to C# but I've
been overruled.

Bye,
Peter
"Terry Olsen" <to******@hotmail.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...

Are the VB6 string functions going away soon? I still find myself using
them because vbCr is much shorter and easier then ControlChars.Cr.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uu**************@tk2msftngp13.phx.gbl...

"Peter Row" <fuck.off@bastard_spammers.com> schrieb:

I am currently working on a VB.NET project that has been going for quite
a while.
In the past it has been developed with a lot of compatibility VB6
functions and
constants, e.g Left(), LCase() and vbCr

These methods are /not/ part of the compatibility library.

myString2 = myString.Replace(vbCr, Environment.NewLine)

However what do I replace vbCr with?

I prefer 'ControlChars.Cr', which is a VB.NET feature.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

"Terry Olsen" <to******@hotmail.com> schrieb:

Are the VB6 string functions going away soon? I still find myself using
them because vbCr is much shorter and easier then ControlChars.Cr.

As Larry said, you can import the type containing 'Cr' and simply use 'Cr'
in your code. There are no public plans to remove VB.NET's string functions
in a future version of VB.NET.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

Peter,

"Peter Row" <fuck.off@bastard_spammers.com> schrieb:

Okay okay, bad wording.
What I mean is that functions like Left() and LCase() etc...
only exist to make old VB6-ers more comfortable.
Does 'Select Case' exist only to make "old VB6ers more comfortable"? I
doubt that! 'Left', etc. are part of the language (implemented in the
Visual Basic .NET Runtime Library).
In a proper .NET app you shouldn't use them because all they
are is wrappers around .NET CLR stuff, i.e. String.ToLower()
That's completely wrong! For some of the functions in
'Microsoft.VisualBasic.Strings' there is no direct equivalent in the .NET
Framework, for example for the 'Mid' assignment function, 'Left' or 'Right'
(notice that using 'Substring' doesn't include as many information for the
reader as 'Left' and 'Right' do). There are some other examples for not
simply duplicating behavior provided in the .NET Framework too. Consider
the 'Len' function, for example:

\\\
Dim s As String = LoadString(Foo)
MsgBox(CStr(Len(s)))
///

would read

\\\
Dim s As String = LoadString(Foo)
Dim n As Integer
If s Is Nothing Then
n = 0
Else
n = s.Length
End If
MsgBox(CStr(n))
///

when not using 'Len'.
Why make multiple calls that can be done with 1?
That's simply not true for many cases.
I'll checkout the ControlChars.Cr but I don't really want
to use anything that is in a VisualBasic Namespace.
Well, do you really want to use Visual Basic .NET without actually using
it?!
Is there not an equivalent of vbCr that is in the standard
System namespaces?

No. In C# you would use "\r" inside a string literal, which is not
supported by VB.NET. For this reason, VB provides its own 'ControlChars'.
The following VB.NET code

\\\
Dim s As String = "Hello" & ControlChars.Tab & "World"
///

is the same as

\\\
string s = "Hello\tWorld";
///

in C#.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Phill. W]

"Peter Row" <fuck.off@bastard_spammers.com> wrote in message
news:eP**************@TK2MSFTNGP15.phx.gbl...

Is there not an equivalent of vbCr that is in the standard
System namespaces?

No, which is why I've been dragged into a long-running, pointless
and utterly stupid argument in my present job. We are primarily
a VB ["Proper"] shop, in the process of moving to VB.Net.

The Standard-authoring .. erm .. persons, .Net zealots and former
C++ gurus the lot of Them, are /trying/ to decree

"Thou shalt not Import Microsoft.VisualBasic"

(Yes; in a VB.Net project, you get this by default).

Amongst other things, I look after a lot of routines that manipulate
Tab delimited data, net least of which their precious application
logging routines, so, to Them, I (and many others) reply

"So**eth off until thou findest me a proper replacement for vbTab!!"

MS.VB is there and not /that/ likely to disappear in the next release,
so I use it when I have to. Mind you, about the /only/ things I use
MS.VB for /is/ vbTab; Oh and CreateObject - don't ask why.

Regards,
Phill W.

[Cor Ligthert]

Peter,

When you write as you do, than there is no need for VBNet at all.

VBNet is a language with a completly different syntax than the C derived
languages.

However there is not any problem to use the Microsoft.VisualBasic namespace
in C# or C++ managed code. It is not done often yet. However the
Microsoft.VisualBasic namespace contains such a lot of strong methods, that
it will in my opinion not take long that more and more C# programmers will
discover that, and start using that.

However just my though,

Cor

[Peter Row]

Hi,

I didn't mean to start a flaming war.
However your example with the Len function is completely
wrong.

I can write exactly the same in the same amount of code.
Try this:

\\\
Dim s As String = (LoadString(foo) & String.Empty)
MessageBox.Show(s.Length.ToString)
///

Guess that sorts that.

As far as 'Select Case' goes that is syntax that controls
program flow it is not a function/sub or a constant. You
don't have to import the VisualBasic namespace to use it.
If you read my original post I am trying to remove the need
for VB6-isms that are functions and constants.

As for 'Mid' it has long been frowned upon for assignment
purposes.

As for Left() / Right() being more readable than Substring()
that is entirely debatable. If ever you see Substring(0, ...) then
you know immediately it is taking characters from the left as you
do with Left(). I conceed that when using Substring() to take
characters from the right then it does not necessarily immediately
scream at you it's taking characters from the right as the Right()
function does.

Frankly if I had the chance I would convert the project to C#
if I were allowed to. Not because I don't like VB.NET, in fact
I did much of my early programming in VB6/VBA, however
I recently worked on a C# project and found it a delight to work
with and now coming back to VB.NET find there are various things
I can't do or can't do in the same way.

For example:

Try this in VB.NET
Dim X As Long = 1000000000
Dim Y() As Byte
ReDim Y(X)

BANG! Cannot implicitly convert long to integer on ReDim
line.

Or how about operator overloading, the simplicity of variable conversion,
the simplicity of adding event handlers.

Look VB.NET is a good language. I however have become a convert
to C# and since on my current project can't use C# I want to use the
standard .NET framework stuff as much as possible. Is that a crime?

Regards,
Peter

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ue**************@TK2MSFTNGP14.phx.gbl...

Peter,

"Peter Row" <fuck.off@bastard_spammers.com> schrieb:

Okay okay, bad wording.
What I mean is that functions like Left() and LCase() etc...
only exist to make old VB6-ers more comfortable.

Does 'Select Case' exist only to make "old VB6ers more comfortable"? I
doubt that! 'Left', etc. are part of the language (implemented in the
Visual Basic .NET Runtime Library).

In a proper .NET app you shouldn't use them because all they
are is wrappers around .NET CLR stuff, i.e. String.ToLower()

That's completely wrong! For some of the functions in
'Microsoft.VisualBasic.Strings' there is no direct equivalent in the .NET
Framework, for example for the 'Mid' assignment function, 'Left' or
'Right' (notice that using 'Substring' doesn't include as many information
for the reader as 'Left' and 'Right' do). There are some other examples
for not simply duplicating behavior provided in the .NET Framework too.
Consider the 'Len' function, for example:

\\\
Dim s As String = LoadString(Foo)
MsgBox(CStr(Len(s)))
///

would read

\\\
Dim s As String = LoadString(Foo)
Dim n As Integer
If s Is Nothing Then
n = 0
Else
n = s.Length
End If
MsgBox(CStr(n))
///

when not using 'Len'.

Why make multiple calls that can be done with 1?

That's simply not true for many cases.

I'll checkout the ControlChars.Cr but I don't really want
to use anything that is in a VisualBasic Namespace.

Well, do you really want to use Visual Basic .NET without actually using
it?!

Is there not an equivalent of vbCr that is in the standard
System namespaces?

No. In C# you would use "\r" inside a string literal, which is not
supported by VB.NET. For this reason, VB provides its own 'ControlChars'.
The following VB.NET code

\\\
Dim s As String = "Hello" & ControlChars.Tab & "World"
///

is the same as

\\\
string s = "Hello\tWorld";
///

in C#.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

"Peter Row" <fuck.off@bastard_spammers.com> schrieb:

I didn't mean to start a flaming war.
However your example with the Len function is completely
wrong.

I can write exactly the same in the same amount of code.
Try this:

\\\
Dim s As String = (LoadString(foo) & String.Empty)
MessageBox.Show(s.Length.ToString)
///
I consider that a very dirty solution.
As far as 'Select Case' goes that is syntax that controls
program flow it is not a function/sub or a constant. You
don't have to import the VisualBasic namespace to use it.
If you read my original post I am trying to remove the need
for VB6-isms that are functions and constants.
The syntax can be seen as VB6-ism too.
As for Left() / Right() being more readable than Substring()
that is entirely debatable. If ever you see Substring(0, ...) then
you know immediately it is taking characters from the left as you
do with Left(). I conceed that when using Substring() to take
characters from the right then it does not necessarily immediately
scream at you it's taking characters from the right as the Right()
function does.
Well, I think that function names should clearly state what the function is
doing. The more clear, the better.
For example:

Try this in VB.NET
Dim X As Long = 1000000000
Dim Y() As Byte
ReDim Y(X)

BANG! Cannot implicitly convert long to integer on ReDim
line.
Well, VB.NET is more strict in this case, which is a /benefit/. Set 'X' to
1000000000000. VB.NET will give you a compile-time warning, but the C# code
will throw an exception at /runtime/! Currently, VB.NET is /more CLS
compliant/ than C# and is at least as strict as C# when 'Option
Strict'/'Option Explicit' are turned on.
Or how about operator overloading, the simplicity of variable conversion,
the simplicity of adding event handlers.

Event handling in VB.NET is more evolved than in C#. In addition to
'AddHandler' and 'RemoveHandler', VB provides declarative event handling
('WithEvents' + 'Handles').

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Cor Ligthert]

Peter,

I don't use the Collection, the LEN, the MID or whatever like that which
uses the First to start as indexer.

Not that it is ancient, however because that it is confusing for me. Not
that I don't find the First starting the best way, but because that there
are more components that start with the Zero as indexer.

That is in my opinion a quiet different reason than as you tell in this
thread.

Cor

[Cor Ligthert]

> Currently, VB.NET is /more CLS compliant/ than C# and is at least as

strict as C# when 'Option Strict'/'Option Explicit' are turned on.

Sample translated to VBNet code

Public mystring as String
Public property MyString as String
.....

This is in C# allowed and throws directly a CLS error when the class is used
in VBNet.
Before you say it, it has to be used as
Private mystring as String
Public property MyString as String

However it is can be done.

Cor

[Peter Row]

Hi,
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:O2****************@TK2MSFTNGP14.phx.gbl...

"Peter Row" <fuck.off@bastard_spammers.com> schrieb:

I didn't mean to start a flaming war.
However your example with the Len function is completely
wrong.

I can write exactly the same in the same amount of code.
Try this:

\\\
Dim s As String = (LoadString(foo) & String.Empty)
MessageBox.Show(s.Length.ToString)
///
I consider that a very dirty solution.

Why?
The only possible bit you could say is dirty is the & String.Empty.
And why not do that? After all thats all the VB.NET VB6 type
functions are doing behind the scences

As far as 'Select Case' goes that is syntax that controls
program flow it is not a function/sub or a constant. You
don't have to import the VisualBasic namespace to use it.
If you read my original post I am trying to remove the need
for VB6-isms that are functions and constants.

The syntax can be seen as VB6-ism too.

Read what I have said in the above paragraph and the original
post. I don't mind the constructs of general lanaguage like If
and Select just the functions which are mere wrappers in a lot
of cases.

As for Left() / Right() being more readable than Substring()
that is entirely debatable. If ever you see Substring(0, ...) then
you know immediately it is taking characters from the left as you
do with Left(). I conceed that when using Substring() to take
characters from the right then it does not necessarily immediately
scream at you it's taking characters from the right as the Right()
function does.

Well, I think that function names should clearly state what the function
is doing. The more clear, the better.

I was talking about a left and right. However SubString() DOES clearly
state what it is doing. It extracts part of a string from an existing one
and
returns it. What does Left(myVariable, 5) tell you? Absolutely nothing.
The name SubString indicates that it works on Strings, Left() does not!

For example:

Try this in VB.NET
Dim X As Long = 1000000000
Dim Y() As Byte
ReDim Y(X)

BANG! Cannot implicitly convert long to integer on ReDim
line.

Well, VB.NET is more strict in this case, which is a /benefit/. Set 'X'
to 1000000000000. VB.NET will give you a compile-time warning, but the C#
code will throw an exception at /runtime/! Currently, VB.NET is /more CLS
compliant/ than C# and is at least as strict as C# when 'Option
Strict'/'Option Explicit' are turned on.

DOH!
VB is not being more strict at all!!!!
VB is STOPPING me from declaring a large byte array().
In C# the code above would declare a large byte array()!
Also in C# you don't have to turn any options on for it to be strict it just
is.

Or how about operator overloading, the simplicity of variable conversion,
the simplicity of adding event handlers.

Event handling in VB.NET is more evolved than in C#. In addition to
'AddHandler' and 'RemoveHandler', VB provides declarative event handling
('WithEvents' + 'Handles').

C# simply shortcuts all of that into the same thing.
i.e. MyObject.MyEvent += MyEventHandler();

WithEvents is not more evolved at all, in VB you have to use that to
indicate that
you objects have events. In C# you'd just use them without having to put any
extra keyword.

Regards,
Peter

[Herfried K. Wagner [MVP]]

Cor,

"Cor Ligthert" <no************@planet.nl> schrieb:

Currently, VB.NET is /more CLS compliant/ than C# and is at least as
strict as C# when 'Option Strict'/'Option Explicit' are turned on.

Sample translated to VBNet code

Public mystring as String
Public property MyString as String
....

This is in C# allowed and throws directly a CLS error when the class is
used in VBNet.
Before you say it, it has to be used as
Private mystring as String
Public property MyString as String

However it is can be done.

ACK. From the CLS:

| For two identifiers to be considered distinct, they must differ
| by more than just their case.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

Peter,

"Peter Row" <fuck.off@bastard_spammers.com> schrieb:

I didn't mean to start a flaming war.
However your example with the Len function is completely
wrong.

I can write exactly the same in the same amount of code.
Try this:

\\\
Dim s As String = (LoadString(foo) & String.Empty)
MessageBox.Show(s.Length.ToString)
///
I consider that a very dirty solution.

Why?

Because useless overhead of a string concatenation is introduced and the
code is harder to understand. The solution you posted is a "workaround". I
wouldn't consider that "best-practice".
The only possible bit you could say is dirty is the & String.Empty.
And why not do that? After all thats all the VB.NET VB6 type
functions are doing behind the scences
Wrong. The implementation of VB.NET's 'Len' function looks like this:

\\\
Public Shared Function Len(ByVal Expression As String) As Integer
If Expression Is Nothing Then
Return 0
End If
Return Expression.Length
End Function
///

As far as 'Select Case' goes that is syntax that controls
program flow it is not a function/sub or a constant. You
don't have to import the VisualBasic namespace to use it.
If you read my original post I am trying to remove the need
for VB6-isms that are functions and constants.

The syntax can be seen as VB6-ism too.

Read what I have said in the above paragraph and the original
post. I don't mind the constructs of general lanaguage like If
and Select just the functions which are mere wrappers in a lot
of cases.

I suggest to take a closer look at 'Microsoft.VisualBasic'. As I have
already said, 'Microsoft.VisualBasic' often extends existing framework
functionality and makes it ready for direct use within the code.

As for Left() / Right() being more readable than Substring()
that is entirely debatable. If ever you see Substring(0, ...) then
you know immediately it is taking characters from the left as you
do with Left(). I conceed that when using Substring() to take
characters from the right then it does not necessarily immediately
scream at you it's taking characters from the right as the Right()
function does.

Well, I think that function names should clearly state what the function
is doing. The more clear, the better.

I was talking about a left and right. However SubString() DOES clearly
state what it is doing. It extracts part of a string from an existing one
and returns it.

It doesn't tell you what part, except if you know all overloads and analyze
the parameters passed to it.
What does Left(myVariable, 5) tell you? Absolutely nothing.
The name SubString indicates that it works on Strings, Left() does not!
Well, does '+' not tell you that it works on numbers?! Everybody who
/learns/ VB.NET will learn what 'Left' does as it's part of Visual Basic
..NET.

For example:

Try this in VB.NET
Dim X As Long = 1000000000
Dim Y() As Byte
ReDim Y(X)

BANG! Cannot implicitly convert long to integer on ReDim
line.

Well, VB.NET is more strict in this case, which is a /benefit/. Set 'X'
to 1000000000000. VB.NET will give you a compile-time warning, but the C#
code will throw an exception at /runtime/! Currently, VB.NET is /more
CLS compliant/ than C# and is at least as strict as C# when 'Option
Strict'/'Option Explicit' are turned on.

DOH!
VB is not being more strict at all!!!!

Please re-read what I wrote. VB.NET is more strict than C# if 'Option
Strict' is turned 'On'.
VB is STOPPING me from declaring a large byte array().
Wrong. The number of items in arrays must be <= 'Int32.MaxValue'. So by
passing an 'Int64' as number of elements a conversion from 'Int64' to
'Int32' must be done. C# does this conversion /implicitly/ which may lead
to exceptions at runtime. VB.NET will make the developer aware of a
possible problem at compile-time, which is much better than the C# approach.
In C# the code above would declare a large byte array()!
No! The code will only work if the number of elements is <=
'Int32.MaxValue', otherwise an exception will be thrown!
Also in C# you don't have to turn any options on for it to be strict it
just is.
In this particular case, C# is not strict at all. In VB.NET, you can enable
'Option Strict' on project level in the project properties.

Or how about operator overloading, the simplicity of variable
conversion,
the simplicity of adding event handlers.

Event handling in VB.NET is more evolved than in C#. In addition to
'AddHandler' and 'RemoveHandler', VB provides declarative event handling
('WithEvents' + 'Handles').

C# simply shortcuts all of that into the same thing.
i.e. MyObject.MyEvent += MyEventHandler();

Wrong. '+=' is the equivalent to 'AddHandler'. C# doesn't provide support
for declarative event handling.
WithEvents is not more evolved at all, in VB you have to use that to
indicate that
you objects have events.

Wrong again. Even if a variable is not declared 'WithEvents', handlers can
be added using 'AddHandler'. 'WithEvents' enables declarative event
handling ('Handles').

I am shocked that people are basing their decisions on such a lack of
knowledge...

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Cor Ligthert]

Herfried,

I am shocked that people are basing their decisions on such a lack of
knowledge...

ACK (although not shocked)

:-)

Cor

[Peter Row]

Hi,

Some bits snipped for clarity and focus.

Before I say anything further I will admit now to the whole
group that I had not fully investigated all of what I had said
certainly the byte[] example.

Now to continue...

"Peter Row" <fuck.off@bastard_spammers.com> schrieb:

I didn't mean to start a flaming war.
However your example with the Len function is completely
wrong.

I can write exactly the same in the same amount of code.
Try this:

\\\
Dim s As String = (LoadString(foo) & String.Empty)
MessageBox.Show(s.Length.ToString)
///

I consider that a very dirty solution.

Why?

Because useless overhead of a string concatenation is introduced and the
code is harder to understand. The solution you posted is a "workaround".
I wouldn't consider that "best-practice".

The only possible bit you could say is dirty is the & String.Empty.
And why not do that? After all thats all the VB.NET VB6 type
functions are doing behind the scences

Wrong. The implementation of VB.NET's 'Len' function looks like this:

\\\
Public Shared Function Len(ByVal Expression As String) As Integer
If Expression Is Nothing Then
Return 0
End If
Return Expression.Length
End Function
///

If that implementation of Len() is correct then why in your original example
code did you write MsgBox(CStr(Len(s)) when the CStr() according to
your implementation of Len is not needed.

As far as 'Select Case' goes that is syntax that controls
program flow it is not a function/sub or a constant. You
don't have to import the VisualBasic namespace to use it.
If you read my original post I am trying to remove the need
for VB6-isms that are functions and constants.

The syntax can be seen as VB6-ism too.

Read what I have said in the above paragraph and the original
post. I don't mind the constructs of general lanaguage like If
and Select just the functions which are mere wrappers in a lot
of cases.

I suggest to take a closer look at 'Microsoft.VisualBasic'. As I have
already said, 'Microsoft.VisualBasic' often extends existing framework
functionality and makes it ready for direct use within the code.

No - I suggest you stop trying to be all high and mighty and read
correctly what I have said. My original post and aim was to remove
functions and constants which are replicated in the framework, i.e.
Left(). You are quick to slap me down when I have made a mistake
and I admited at the start of this message that I had. However when
I make a valid point or slap you down your response is to go off on
a completely different tangent. Example: My response regarding use
of Select...Case...

What does Left(myVariable, 5) tell you? Absolutely nothing.
The name SubString indicates that it works on Strings, Left() does not!

Well, does '+' not tell you that it works on numbers?! Everybody who
/learns/ VB.NET will learn what 'Left' does as it's part of Visual Basic
.NET.

+ could work on number but it could just as well work on strings.
Your argument seems to say "read the function called, ignore all the
parameters involved and you should be able to say exactly what is
happening".

Left(myVariable, 5) does not necessarily tell you that it is working with
strings. And you have fallen foul of your own argument. You say, and I
quote "Everybody who /learns/ VB.NET will learn what 'Left' does",
so therefore why is it so bad to /learn/ what Substring() does and use
that instead of Left(). And don't say "because it's easier to read" because
it is not. You either know what a function is for or you don't and when
reading code to find out what it's doing you read it and take into account
the parameters passed not just the name of the function.

For example:

Try this in VB.NET
Dim X As Long = 1000000000
Dim Y() As Byte
ReDim Y(X)

BANG! Cannot implicitly convert long to integer on ReDim
line.
Bad example I was wrong. In C# this would cause a runtime error because
X is a long.
Or how about operator overloading, the simplicity of variable
conversion,
the simplicity of adding event handlers.

Event handling in VB.NET is more evolved than in C#. In addition to
'AddHandler' and 'RemoveHandler', VB provides declarative event handling
('WithEvents' + 'Handles').

C# simply shortcuts all of that into the same thing.
i.e. MyObject.MyEvent += MyEventHandler();

Wrong. '+=' is the equivalent to 'AddHandler'. C# doesn't provide
support for declarative event handling.

WithEvents is not more evolved at all, in VB you have to use that to
indicate that
you objects have events.

Wrong again. Even if a variable is not declared 'WithEvents', handlers
can be added using 'AddHandler'. 'WithEvents' enables declarative event
handling ('Handles').

I am shocked that people are basing their decisions on such a lack of
knowledge...

I have not checked if what you have said about WithEvents is correct but
it sounds like you are. I apologise for not checking myself first.

However again you have sidestepped all the other things I pointed out
to pick on a single thing. You have not said anything in return to:

- VB has no operator overloading, C# does.
- VB requires use of function calls when adding event handlers
programmatically
C# does not.
- VB requires a function call to convert the simplest of types C# does not,
i.e.:
CStr(myNumber) as opposed to - (string)myNumber

Regards,
Peter

[Cor Ligthert]

Peter,

Some bits snipped for clarity and focus.

Before I say anything further I will admit now to the whole
group that I had not fully investigated all of what I had said
certainly the byte[] example.

Now to continue...

I would not do that when I was you, in my opinion do you have in a lot of
sentences right as you wrote in this message. However what importance has
it.

Use from VBNet what you fits the best. However don't use something *not*
because the only fact is that it is in the Microsoft.VisualBasic namespace.
That is something what is the same as all other standard with Net included
namespaces.

That is the nice thing from VBNet you are not sticked to one method. As I
write forever that is the same as in a natural language, were you can use
completely different ways your opinion, while you use a slightly different
word with almost the same meaning.

Cor

[Alejandro Lapeyre]

Maybe he is learning c# too, but knows more VB.
So, maybe, he wants to learn something that he may use in c#.

It seems that when someone ask this kind of questions, should preface the
question with
"How would you do this in c#?"

Best Regards,
Alejandro Lapeyre
"Cor Ligthert" <no************@planet.nl> escribió en el mensaje
news:eF**************@TK2MSFTNGP15.phx.gbl...

Peter,

Some bits snipped for clarity and focus.

Before I say anything further I will admit now to the whole
group that I had not fully investigated all of what I had said
certainly the byte[] example.

Now to continue...

I would not do that when I was you, in my opinion do you have in a lot of
sentences right as you wrote in this message. However what importance has
it.

Use from VBNet what you fits the best. However don't use something *not*
because the only fact is that it is in the Microsoft.VisualBasic
namespace. That is something what is the same as all other standard with
Net included namespaces.

That is the nice thing from VBNet you are not sticked to one method. As I
write forever that is the same as in a natural language, were you can use
completely different ways your opinion, while you use a slightly different
word with almost the same meaning.

Cor

[Herfried K. Wagner [MVP]]

Peter,

"Peter Row" <fuck.off@bastard_spammers.com> schrieb:

The only possible bit you could say is dirty is the & String.Empty.
And why not do that? After all thats all the VB.NET VB6 type
functions are doing behind the scences
Wrong. The implementation of VB.NET's 'Len' function looks like this:

\\\
Public Shared Function Len(ByVal Expression As String) As Integer
If Expression Is Nothing Then
Return 0
End If
Return Expression.Length
End Function
///

If that implementation of Len() is correct then why in your original
example
code did you write MsgBox(CStr(Len(s)) when the CStr() according to
your implementation of Len is not needed.

Notice that 'Len'/'String.Length' return an 'Int32', which must be converted
to a string either explicitly or implicitly to be shown as part of the
messagebox's text. 'CStr' is simply VB.NET's replacement of 'ToString'.
Both are not mandatory, even when 'Option Strict' is set to 'On', but it's
better to explicitly specify them to make more clear that the developer who
wrote the code knew what he/she was doing :-).

> As far as 'Select Case' goes that is syntax that controls
> program flow it is not a function/sub or a constant. You
> don't have to import the VisualBasic namespace to use it.
> If you read my original post I am trying to remove the need
> for VB6-isms that are functions and constants.

The syntax can be seen as VB6-ism too.

Read what I have said in the above paragraph and the original
post. I don't mind the constructs of general lanaguage like If
and Select just the functions which are mere wrappers in a lot
of cases.

I suggest to take a closer look at 'Microsoft.VisualBasic'. As I have
already said, 'Microsoft.VisualBasic' often extends existing framework
functionality and makes it ready for direct use within the code. No - I suggest you stop trying to be all high and mighty and read
correctly what I have said. My original post and aim was to remove
functions and constants which are replicated in the framework, i.e.
Left().
From my point of view, there is no 1:1 replacement for 'Left'. There is a
method that can be used to archieve the same result, but is more low-level
because it is more generic in name and functionality. Maybe 'Left' is not
the best example. Consider the 'Right' method. 'Right' cannot be replaced
by 'Substring' directly without doing some position calculations.
'Strings.*' provides a complete and consistent set of functions for string
manipulation. 'Mid' assignment, 'Right', 'Split', for example, do not
duplicate functionality provided by the 'String' class.

What does Left(myVariable, 5) tell you? Absolutely nothing.
The name SubString indicates that it works on Strings, Left() does not!

Well, does '+' not tell you that it works on numbers?! Everybody who
/learns/ VB.NET will learn what 'Left' does as it's part of Visual Basic
.NET.

+ could work on number but it could just as well work on strings.
Your argument seems to say "read the function called, ignore all the
parameters involved and you should be able to say exactly what is
happening".

That's what I mean. The more information a function's name carries the
better. When reading 'Left' or 'Right', I know more about what's done when
reading 'Substring'. In a 2nd step, I analyze the parameters.
Left(myVariable, 5) does not necessarily tell you that it is working with
strings. And you have fallen foul of your own argument.
Why doesn't it tell that it's working with strings? That's what every
VB.NET programmer should know...
You say, and I quote "Everybody who /learns/ VB.NET will
learn what 'Left' does", so therefore why is it so bad to /learn/
what Substring() does and use that instead of Left(). And don't
say "because it's easier to read" because it is not.
My answer is that 'Left' is easier to read. The name simply contains more
information than 'Substring'. It's not bad to learn what 'Substring' does,
but even when knowing that it either takes a part of the string from the
left side or a part from the middle of the string the reader will have to
analyze the parameter list to decide what's done.
You either know what a function is for or you don't and when
reading code to find out what it's doing you read it and take into account
the parameters passed not just the name of the function.
The name of the function gives a fist idea of what's going on, which is very
important. Otherwise we could simply name methods from 'Method1' to
'Methodn' and always rely on analyzing the parameter list.

I am shocked that people are basing their decisions on such a lack of
knowledge...

I have not checked if what you have said about WithEvents is correct but
it sounds like you are. I apologise for not checking myself first.

No problem. We are all here to learn :-).
- VB has no operator overloading, C# does.
VB 2005 will contain operator overloading.
- VB requires use of function calls when adding event handlers
programmatically
No. 'AddHandler' is not a function, it's a statement.
C# does not.
- VB requires a function call to convert the simplest of types C# does
not, i.e.:
CStr(myNumber) as opposed to - (string)myNumber

Although 'CStr' looks like a function call, 'CStr' does the same as
'(string)' in C# (casting or conversion, depending on the case).

MSDN:

| These ['C*'] keywords act like functions, but the compiler generates
| the code inline, so execution is slightly faster than with a function
call.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Cor Ligthert]

Herfried,

This depends all where you come from, although English is not a problem for
you, you probably prefer Bier over Beer.

That does not mean that American beer is bad. I find them very good, maybe
that I am there eyes a snob because I more likely drink Heineken. However
that is because it is opposite from in the US cheaper here than Budweiser
(The american one, I prefer of course the most the real Budweiser or Urquel
from fust.) However all that is personal.

I think it is the same with
substring and Microsoft VisualBasic string functions,

Just my thought,
(I never drink beer anymore)

:-)

Cor

[Herfried K. Wagner [MVP]]

Cor,

"Cor Ligthert" <no************@planet.nl> schrieb:

This depends all where you come from, although English is not a problem
for you, you probably prefer Bier over Beer.

That does not mean that American beer is bad. I find them very good, maybe
that I am there eyes a snob because I more likely drink Heineken. However
that is because it is opposite from in the US cheaper here than Budweiser
(The american one, I prefer of course the most the real Budweiser or
Urquel from fust.) However all that is personal.

I think it is the same with
substring and Microsoft VisualBasic string functions,

I agree that it's up to personal preference to decide whether to use
VB.NET's string functions or those provided by .NET. However, I typically
base my preferences on in-depth evaluation of the different options to
choose from (this doesn't mean that I drink a lot of beer ;-)) instead of
basing them on ideological reasons.

Just my 2 Euro cents...

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>