By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,677 Members | 1,174 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,677 IT Pros & Developers. It's quick & easy.

Microsoft.VisualBasic.Left Function

P: n/a
I know I can use the Microsoft.VisualBasic.Left function to get the left
portion of a string, but I would prefer to avoid using any
Microsoft.VisualBasic namespace items. What is the equivilant in VB.Net
2005?

Thank You
Greg
Jun 27 '08 #1
Share this Question
Share on Google+
32 Replies


P: n/a
The .SubString method of the string

"Greg" <gj******@COMCAST.NETwrote in message
news:eE**************@TK2MSFTNGP04.phx.gbl...
>I know I can use the Microsoft.VisualBasic.Left function to get the left
portion of a string, but I would prefer to avoid using any
Microsoft.VisualBasic namespace items. What is the equivilant in VB.Net
2005?

Thank You
Greg
Jun 27 '08 #2

P: n/a
"Greg" <gj******@COMCAST.NETschrieb
I know I can use the Microsoft.VisualBasic.Left function to get the
left portion of a string, but I would prefer to avoid using any
Microsoft.VisualBasic namespace items. What is the equivilant in
VB.Net 2005?
The String has a SubString method.
Armin
Jun 27 '08 #3

P: n/a
"Greg" <gj******@COMCAST.NETschrieb:
>I know I can use the Microsoft.VisualBasic.Left function to get the left
portion of a string, but I would prefer to avoid using any
Microsoft.VisualBasic namespace items. What is the equivilant in VB.Net
2005?
Why would you want to use VB without actually using it?

A rough equivalent is provided by the 'String.Substring' method.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Jun 27 '08 #4

P: n/a
Why would you want to use VB without actually using it?

A great many people feel the same way as the OP, in that they would prefer
not to use language-specific functions to manipulate objects, when the
objects themselves provide the same functionality.

Some dislike using the legacy functions of VB for fear that at some point in
the future MS will deprecate them.
Some dislike using them because they want their code to be more easily
ported to another .NET language in the future.
Some dislike using them because their usage doesn't feel like true OO syntax
(just calling a method without specifying an object or type).

I'm sure you know about these points and that it has been debated over and
over again. But, not wanting to use these legacy VB functions is a
perfectly resonable approach to VB .NET.

-Scott
Jun 27 '08 #5

P: n/a
Greg,

Why do you want only to use a part of the Net framework as you can use the
whole framework?

Sounds to me as buying a Mercedes but want to driver it like a bicycle.

Cor

"Greg" <gj******@COMCAST.NETschreef in bericht
news:eE**************@TK2MSFTNGP04.phx.gbl...
>I know I can use the Microsoft.VisualBasic.Left function to get the left
portion of a string, but I would prefer to avoid using any
Microsoft.VisualBasic namespace items. What is the equivilant in VB.Net
2005?

Thank You
Greg
Jun 27 '08 #6

P: n/a
See my response to Herfried.
"Cor Ligthert[MVP]" <no************@planet.nlwrote in message
news:41**********************************@microsof t.com...
Greg,

Why do you want only to use a part of the Net framework as you can use the
whole framework?

Sounds to me as buying a Mercedes but want to driver it like a bicycle.

Cor

"Greg" <gj******@COMCAST.NETschreef in bericht
news:eE**************@TK2MSFTNGP04.phx.gbl...
>>I know I can use the Microsoft.VisualBasic.Left function to get the left
portion of a string, but I would prefer to avoid using any
Microsoft.VisualBasic namespace items. What is the equivilant in VB.Net
2005?

Thank You
Greg

Jun 27 '08 #7

P: n/a
Also, just to follow up on that. I have 2 very large multi-national clients
that don't want their developers using these "legacy" funcation for just the
reasons I've stated.

This topic has been debated many times over the years and it boils down to
"to each, his/her own", but it doesn't make the argument for one approach
better or worse than the other.

-Scott
"Cor Ligthert[MVP]" <no************@planet.nlwrote in message
news:41**********************************@microsof t.com...
Greg,

Why do you want only to use a part of the Net framework as you can use the
whole framework?

Sounds to me as buying a Mercedes but want to driver it like a bicycle.

Cor

"Greg" <gj******@COMCAST.NETschreef in bericht
news:eE**************@TK2MSFTNGP04.phx.gbl...
>>I know I can use the Microsoft.VisualBasic.Left function to get the left
portion of a string, but I would prefer to avoid using any
Microsoft.VisualBasic namespace items. What is the equivilant in VB.Net
2005?

Thank You
Greg

Jun 27 '08 #8

P: n/a

"Scott M." <sm**@nospam.nospamwrote in message
news:Ow*************@TK2MSFTNGP02.phx.gbl...
>Why would you want to use VB without actually using it?

A great many people feel the same way as the OP, in that they would prefer
not to use language-specific functions to manipulate objects, when the
objects themselves provide the same functionality.

Some dislike using the legacy functions of VB for fear that at some point
in the future MS will deprecate them.
Some dislike using them because they want their code to be more easily
ported to another .NET language in the future.
Some dislike using them because their usage doesn't feel like true OO
syntax (just calling a method without specifying an object or type).

I'm sure you know about these points and that it has been debated over and
over again. But, not wanting to use these legacy VB functions is a
perfectly resonable approach to VB .NET.

I tend to agree. If there is a method on the Object, or for that matter an
extension method, then I'm going to favour using them rather than a method
in another library that doesn't seem related to the Object. It's a matter
of discoverability, and hence lessens the amount you need to remember ;)

Jun 27 '08 #9

P: n/a
Scott,

I never use the Left and Mid.

However the reason is different. I have the opinion that the relation to
First and One is the normal way.

However, the use of First and Zero is in my opinion the largest legancy
their is in computer busines. I avoid using the First as index point as some
Microsoft Visual Basic functions do, just because it is still not well done
in any language.

Trying to make it more clear, that Zero starting point legancy comes purely
from hardware languages and is never changed. while everthings else has back
to normal human use in programming languages. This try with Visual Basic
never succeed. Don't tell this is normal, it is not. You use a lot of
mathimatical operators, which are not direct used in microcomputers, so why
would that needed with indexing.

However a lot of functions in Visual Basic are very helpfull, and because
they are standard part of the Framework, there is no anyneed to avoid them.
Why would I avoid AdoNet while there now is Linq. That VisualBasic is in the
Microsoft namespace and the rest not, had in my idea only a political reason
when Net started.

That your clients have other thoughts, let them go, but don't forget to let
them pay for that you cannot use very well functions.
Maybe they ask you tomorrow to uce only pencils and no computer anymore. You
never know with this kind of clients.
Cor


"Scott M." <sm**@nospam.nospamschreef in bericht
news:Ow*************@TK2MSFTNGP02.phx.gbl...
>Why would you want to use VB without actually using it?

A great many people feel the same way as the OP, in that they would prefer
not to use language-specific functions to manipulate objects, when the
objects themselves provide the same functionality.

Some dislike using the legacy functions of VB for fear that at some point
in the future MS will deprecate them.
Some dislike using them because they want their code to be more easily
ported to another .NET language in the future.
Some dislike using them because their usage doesn't feel like true OO
syntax (just calling a method without specifying an object or type).

I'm sure you know about these points and that it has been debated over and
over again. But, not wanting to use these legacy VB functions is a
perfectly resonable approach to VB .NET.

-Scott
Jun 27 '08 #10

P: n/a
Greg wrote:
I know I can use the Microsoft.VisualBasic.Left function to get the
left portion of a string, but I would prefer to avoid using any
Microsoft.VisualBasic namespace items. What is the equivilant in
VB.Net 2005?
Remember that Microsoft.VisualBasic.Left deals gracefully with (i.e. doesn't
throw an exception for) strings that are Nothing and also strings that are
not long enough.

So, if you want the same functionality, you would have to write your own
version of it.

Andrew
Jun 27 '08 #11

P: n/a
"Scott M." <sm**@nospam.nospamwrote in message
news:Ow*************@TK2MSFTNGP02.phx.gbl...
>Why would you want to use VB without actually using it?

A great many people feel the same way as the OP, in that they would prefer
not to use language-specific functions to manipulate objects, when the
objects themselves provide the same functionality.

Some dislike using the legacy functions of VB for fear that at some point
in the future MS will deprecate them.
Some dislike using them because they want their code to be more easily
ported to another .NET language in the future.
Some dislike using them because their usage doesn't feel like true OO
syntax (just calling a method without specifying an object or type).

I'm sure you know about these points and that it has been debated over and
over again. But, not wanting to use these legacy VB functions is a
perfectly resonable approach to VB .NET.

-Scott
If that's the way someone feels about the intrinsic VB functions, they
should use C#. However, there is a good reason to not use the Left and
Right string functions in VB and that is that they are basically useless in
a Windows Forms object as the Form.Left and Form.Right override them. The
other intrinsic VB functions are perfectly reasonable to use as they also
intelligently deal with string casing (assuming Option Compare Text) and
empty strings or other object. The single biggest strengths of Basic over C
derived languages are the case insensitivity and semi-intelligent string
handlers.

Mike.
Jun 27 '08 #12

P: n/a
"Scott M." <sm**@nospam.nospamwrote in message
news:ul**************@TK2MSFTNGP02.phx.gbl...
Also, just to follow up on that. I have 2 very large multi-national
clients that don't want their developers using these "legacy" funcation
for just the reasons I've stated.
In that case, use C# for their projects.

Mike.
This topic has been debated many times over the years and it boils down to
"to each, his/her own", but it doesn't make the argument for one approach
better or worse than the other.

-Scott
"Cor Ligthert[MVP]" <no************@planet.nlwrote in message
news:41**********************************@microsof t.com...
>Greg,

Why do you want only to use a part of the Net framework as you can use
the whole framework?

Sounds to me as buying a Mercedes but want to driver it like a bicycle.

Cor

"Greg" <gj******@COMCAST.NETschreef in bericht
news:eE**************@TK2MSFTNGP04.phx.gbl...
>>>I know I can use the Microsoft.VisualBasic.Left function to get the left
portion of a string, but I would prefer to avoid using any
Microsoft.VisualBasic namespace items. What is the equivilant in VB.Net
2005?

Thank You
Greg




Jun 27 '08 #13

P: n/a

"Cor Ligthert[MVP]" <no************@planet.nlwrote in message
news:4C**********************************@microsof t.com...
However a lot of functions in Visual Basic are very helpfull, and because
they are standard part of the Framework, there is no anyneed to avoid
them. Why would I avoid AdoNet while there now is Linq. That VisualBasic
is in the Microsoft namespace and the rest not, had in my idea only a
political reason when Net started.

That your clients have other thoughts, let them go, but don't forget to
let them pay for that you cannot use very well functions.
Maybe they ask you tomorrow to uce only pencils and no computer anymore.
You never know with this kind of clients.
Cor
I think you've missed my point Cor. If there are 2 ways to get the same job
done and one is more consistent with the overall framework and doesn't lead
me into a possible dead-end, I'm going to go for that one. A great many
people out there wouldn't be surprised if support for these functions were
to disappear in the futue and then your code would have to be re-worked, but
mine won't.

-Scott
Jun 27 '08 #14

P: n/a
If that's the way someone feels about the intrinsic VB functions, they
should use C#.
That's not really reasonable to say at all. The choice of what .NET
language to use has always been about preference, not requirments.
The single biggest strengths of Basic over C derived languages are the
case insensitivity and semi-intelligent string handlers.
Well, I accept that as your opinion, but not a fact. While I agree with
you, again this is an opinion. I can line up 100 people that will tell you
that case insensitivity is a bad thing.

Anyway, this just goes to my point that a good argument can be made either
way on this, and both arguments have merit.

-Scott
Jun 27 '08 #15

P: n/a
In that case, use C# for their projects.
>
Mike.
As I stated in my other post, the reasoning to jump to a different .NET
language just because legacy VB functions are avoided makes no sense. My
clients can still accomplish everything they want to with the VB .NET
language, so there is no reason to switch languages.

Your suggestion assumes that someone is at a starting point with .NET and
beginning from a clean slate, which is not always the case.

-Scott
Jun 27 '08 #16

P: n/a
"Scott M." <sm**@nospam.nospamschrieb:
>Why would you want to use VB without actually using it?

A great many people feel the same way as the OP, in that they would prefer
not to use language-specific functions to manipulate objects, when the
objects themselves provide the same functionality.
I am aware that this topic has been discussed endlessly. However, each
programming language provides its unique syntax/shortcuts. Thus code is
always tied to a certain programming language, even in .NET. The equivalent
behavior can be achieved in IL, but it does not necessarily map to the same
language constructs and method calls. Lots of 'Select Case' blocks may not
be directly converted to C#'s 'switch' because functionality of these
statements is different (VB's 'Select Case' is more powerful). If one does
not use 'Left', why not stop using 'Select Case' too?
Some dislike using the legacy functions of VB for fear that at some point
in the future MS will deprecate them.
VB's syntax is mostly legacy syntax, as is C#'s syntax. I don't think it
makes sense to draw a line between language syntax and the VB runtime
library, which has always been tied heavily to the programming language.

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

Jun 27 '08 #17

P: n/a
Hello Michael,
However, there is a good reason to not use the Left and
Right string functions in VB and that is that they are basically useless
in a Windows Forms object as the Form.Left and Form.Right override
them.
You are correct and you are wrong.

You are correct, if you only type something like
String1 = Left(String2,1)

But you could write it like this:
String1 = Strings.Left(String2,1)

This even works in VB6...

Best regards,

Martin
Jun 27 '08 #18

P: n/a
"Cor Ligthert[MVP]" <no************@planet.nlschrieb:
However, the use of First and Zero is in my opinion the largest legancy
their is in computer busines. I avoid using the First as index point as
some Microsoft Visual Basic functions do, just because it is still not
well done in any language.

Trying to make it more clear, that Zero starting point legancy comes
purely from hardware languages and is never changed. while everthings else
has back to normal human use in programming languages. This try with
Visual Basic never succeed.
It worked fine in VB6. I almost everywhere used indices running from 1 to n
there instead of 0 to n - 1. It was much more intuitive than 0-based
indices. The problem arises in .NET-based languages because most types
(arrays, collections, ...) expect 0-based indices, thus causing a mix
throughout libraries which use 1-based and 0-based indices respectively.

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

Jun 27 '08 #19

P: n/a

"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
If one does not use 'Left', why not stop using 'Select Case' too?
Because the BCL offers a way to do Left, but does not offer a way to do a
Case block. I guess I'm stating the "purist" point of view: "If the BCL can
do the job, let it.".
Some dislike using the legacy functions of VB for fear that at some point
>in the future MS will deprecate them.

VB's syntax is mostly legacy syntax, as is C#'s syntax. I don't think it
makes sense to draw a line between language syntax and the VB runtime
library, which has always been tied heavily to the programming language.
As I've said, both the pro/con arguments have merit and this is really my
point. Just as you have your opinion about what makes sense, others have a
different opinion. It doesn't make yours or mine correct or incorrect, just
different.

To return to my original reply to your question: "Why would you want to use
VB without actually using it?", a reasonable case can be made (which I've
explained) for not using these functions and a reasonable case can be made
for using them.
Jun 27 '08 #20

P: n/a
"Scott M." <sm**@nospam.nospamschrieb:
I think you've missed my point Cor. If there are 2 ways to get the same
job done and one is more consistent with the overall framework and doesn't
lead me into a possible dead-end, I'm going to go for that one. A great
many people out there wouldn't be surprised if support for these functions
were to disappear in the futue and then your code would have to be
re-worked, but mine won't.
Just give me one reason why these functions are more likely to disappear
than those in the .NET Framework. Both are well-tested code, and both are
heavily used. Note that they have even survived the pre-.NET/.NET migration
step!

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

Jun 27 '08 #21

P: n/a
"Herfried K. Wagner [MVP]" <hi***************@gmx.atschrieb
"Scott M." <sm**@nospam.nospamschrieb:
I think you've missed my point Cor. If there are 2 ways to get
the same job done and one is more consistent with the overall
framework and doesn't lead me into a possible dead-end, I'm going
to go for that one. A great many people out there wouldn't be
surprised if support for these functions were to disappear in the
futue and then your code would have to be re-worked, but mine
won't.

Just give me one reason why these functions are more likely to
disappear than those in the .NET Framework. Both are well-tested
code, and both are heavily used. Note that they have even survived
the pre-.NET/.NET migration step!
One reason might be that there will be less and less people who know
these functions from the VB6 (and earlier) times, and people that are
new to it probably don't find a reason to make the detour to the MSVB
namespace, which are mainly wrappers to the other Framework functions. I
have no problem if they are used, but I myself only use the good
old Msgbox function (IIRC).

I believe that future releases of the Framework won't contain the MSVB
functions anymore because they are not really necessary, but I think
this won't happen in the next 3-5 years.

Even if the features we are talking about are not in the Compatibility
namespace, they are mainly there to make it easier for the VB Clasic
people to accomodate to the managed world, and to avoid more complaints
like "everything is different now!"

Armin

Jun 27 '08 #22

P: n/a
Exactly!
"Armin Zingler" <az*******@freenet.dewrote in message
news:OO***************@TK2MSFTNGP06.phx.gbl...
"Herfried K. Wagner [MVP]" <hi***************@gmx.atschrieb
>"Scott M." <sm**@nospam.nospamschrieb:
I think you've missed my point Cor. If there are 2 ways to get
the same job done and one is more consistent with the overall
framework and doesn't lead me into a possible dead-end, I'm going
to go for that one. A great many people out there wouldn't be
surprised if support for these functions were to disappear in the
futue and then your code would have to be re-worked, but mine
won't.

Just give me one reason why these functions are more likely to
disappear than those in the .NET Framework. Both are well-tested
code, and both are heavily used. Note that they have even survived
the pre-.NET/.NET migration step!

One reason might be that there will be less and less people who know
these functions from the VB6 (and earlier) times, and people that are
new to it probably don't find a reason to make the detour to the MSVB
namespace, which are mainly wrappers to the other Framework functions. I
have no problem if they are used, but I myself only use the good
old Msgbox function (IIRC).

I believe that future releases of the Framework won't contain the MSVB
functions anymore because they are not really necessary, but I think
this won't happen in the next 3-5 years.

Even if the features we are talking about are not in the Compatibility
namespace, they are mainly there to make it easier for the VB Clasic
people to accomodate to the managed world, and to avoid more complaints
like "everything is different now!"

Armin

Jun 27 '08 #23

P: n/a
Well, one could say that even VB.NET is only contained in VS to make it
easier for the VB Classic people to acommodate to the managed world.
One could also say that all programming languages exist to make it easier
for people who don't understand binary code to write programming
instructions, but how does that statement have any relevance to the point
that the legacy functions are largely a duplication of what's already in the
BCL?
Do you have the fear that VB would disappear from the .NET Framework?
I think that I've (and others) have made it clear that we do think that
portions of the VB language will dissapear, at some point, yes.
I think avoiding to use the function is ad-hoc pessimism.
Ok. But, pessimism <bad thing. After all, have you ever used pessimistic
record locking? :)

-Scott
Jun 27 '08 #24

P: n/a
"Armin Zingler" <az*******@freenet.deschrieb:
I think you've missed my point Cor. If there are 2 ways to get
the same job done and one is more consistent with the overall
framework and doesn't lead me into a possible dead-end, I'm going
to go for that one. A great many people out there wouldn't be
surprised if support for these functions were to disappear in the
futue and then your code would have to be re-worked, but mine
won't.

Just give me one reason why these functions are more likely to
disappear than those in the .NET Framework. Both are well-tested
code, and both are heavily used. Note that they have even survived
the pre-.NET/.NET migration step!

One reason might be that there will be less and less people who know
these functions from the VB6 (and earlier) times, and people that are
new to it probably don't find a reason to make the detour to the MSVB
namespace, which are mainly wrappers to the other Framework functions. I
have no problem if they are used, but I myself only use the good
old Msgbox function (IIRC).

I believe that future releases of the Framework won't contain the MSVB
functions anymore because they are not really necessary, but I think
this won't happen in the next 3-5 years.

Even if the features we are talking about are not in the Compatibility
namespace, they are mainly there to make it easier for the VB Clasic
people to accomodate to the managed world, and to avoid more complaints
like "everything is different now!"
Well, one could say that even VB.NET is only contained in VS to make it
easier for the VB Classic people to acommodate to the managed world. Do you
have the fear that VB would disappear from the .NET Framework? I think
avoiding to use the function is ad-hoc pessimism.

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

Jun 27 '08 #25

P: n/a
"Herfried K. Wagner [MVP]" <hi***************@gmx.atschrieb
"Armin Zingler" <az*******@freenet.deschrieb:
I think you've missed my point Cor. If there are 2 ways to
get the same job done and one is more consistent with the
overall
framework and doesn't lead me into a possible dead-end, I'm
going to go for that one. A great many people out there
wouldn't be
surprised if support for these functions were to disappear in
the futue and then your code would have to be re-worked, but
mine
won't.
>
Just give me one reason why these functions are more likely to
disappear than those in the .NET Framework. Both are
well-tested code, and both are heavily used. Note that they
have even survived the pre-.NET/.NET migration step!
One reason might be that there will be less and less people who
know these functions from the VB6 (and earlier) times, and people
that are new to it probably don't find a reason to make the detour
to the MSVB namespace, which are mainly wrappers to the other
Framework functions. I have no problem if they are used, but I
myself only use the good
old Msgbox function (IIRC).

I believe that future releases of the Framework won't contain the
MSVB functions anymore because they are not really necessary, but
I think this won't happen in the next 3-5 years.

Even if the features we are talking about are not in the
Compatibility namespace, they are mainly there to make it easier
for the VB Clasic people to accomodate to the managed world, and
to avoid more complaints like "everything is different now!"

Well, one could say that even VB.NET is only contained in VS to make
it easier for the VB Classic people to acommodate to the managed
world.
I think that's even true. (Why have different languages? Why are there
different car brands?)
However, dropping the whole VB is not comparable to dropping these
functions because it's only a (minor) subset of the whole package.
Do you have the fear that VB would disappear from the .NET
Framework?
I don't have any fears because I didn't give an evaluation of these
functions. I only gave my interpretation why the functions are still
there and what will happen to them in the future - and maybe even VB
will even disappear one day, but that's nothing that anybody can read in
the crystal ball this day.
I think avoiding to use the function is ad-hoc
pessimism.
Which pessimism? You mean my estimation that they will be dropped one
day? Well, I think this is the natural development because there is no
need to artifically keep alife redundant stuff that will be used less
and less in the future for the reason given. I don't think this is a bad
development. I don't think it's bad to use them now, however, every time
I teach VB noobs, I don't see a single reason to show them the MSVB
namespace.
Armin

Jun 27 '08 #26

P: n/a
"Scott M." <sm**@nospam.nospamschrieb:
>Well, one could say that even VB.NET is only contained in VS to make it
easier for the VB Classic people to acommodate to the managed world.

One could also say that all programming languages exist to make it easier
for people who don't understand binary code to write programming
instructions, but how does that statement have any relevance to the point
that the legacy functions are largely a duplication of what's already in
the BCL?
VB is maybe a duplication of C# (the "#1 .NET programming language") which
exists only for compatibility purposes ;-).
>Do you have the fear that VB would disappear from the .NET Framework?

I think that I've (and others) have made it clear that we do think that
portions of the VB language will dissapear, at some point, yes.
I have seen that for sure and I do not completely disagree because I know
how Microsoft values compatibility and "language stability". I, however, do
not share the pessimism about the future of a certain part of Visual Basic
without being pessimistic about the whole programming language. Note that I
am not pessimistic about VB's future, but I am not too optimistic too.
>I think avoiding to use the function is ad-hoc pessimism.

Ok. But, pessimism <bad thing. After all, have you ever used
pessimistic record locking? :)
;-)

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

Jun 27 '08 #27

P: n/a
>One could also say that all programming languages exist to make it easier
>for people who don't understand binary code to write programming
instructions, but how does that statement have any relevance to the point
that the legacy functions are largely a duplication of what's already in
the BCL?

VB is maybe a duplication of C# (the "#1 .NET programming language") which
exists only for compatibility purposes ;-).
I would just say that I don't see how VB can be a duplication of C# if VB
was around first.

:)

Jun 27 '08 #28

P: n/a
Hi Armin,

"Armin Zingler" <az*******@freenet.dewrote in message
news:OO***************@TK2MSFTNGP06.phx.gbl...
"Herfried K. Wagner [MVP]" <hi***************@gmx.atschrieb
>"Scott M." <sm**@nospam.nospamschrieb:
I think you've missed my point Cor. If there are 2 ways to get
the same job done and one is more consistent with the overall
framework and doesn't lead me into a possible dead-end, I'm going
to go for that one. A great many people out there wouldn't be
surprised if support for these functions were to disappear in the
futue and then your code would have to be re-worked, but mine
won't.

Just give me one reason why these functions are more likely to
disappear than those in the .NET Framework. Both are well-tested
code, and both are heavily used. Note that they have even survived
the pre-.NET/.NET migration step!

One reason might be that there will be less and less people who know
these functions from the VB6 (and earlier) times, and people that are
new to it probably don't find a reason to make the detour to the MSVB
namespace, which are mainly wrappers to the other Framework functions. I
have no problem if they are used, but I myself only use the good
old Msgbox function (IIRC).

I believe that future releases of the Framework won't contain the MSVB
functions anymore because they are not really necessary, but I think
this won't happen in the next 3-5 years.

I don't think this will happen at all. But, there are places such as
Silverlight, wehre a cut down set of functionality will require that soem of
the VB nicities aren't there.
Even if the features we are talking about are not in the Compatibility
namespace, they are mainly there to make it easier for the VB Clasic
people to accomodate to the managed world, and to avoid more complaints
like "everything is different now!"
For the most part, yes. About the only thing I use explicitly from the VB
namespaces is ChrW. I use to remove the project wide Import, and then add :

Imports VB= Microsoft.VisualBasic

Then I could write things like VB.Left(....), but I only do that when I need
VB.ChrW wide now days.



Jun 27 '08 #29

P: n/a
Herfried,

I won't call VB Net a duplication of C#. I would more call C# a duplication
of VB with legancy semantic from C.
That in the C# world elitair words are used should not mislead us.

Or in other words. It are two languages with the same parents.

As we see the VAR now in C# (which is the modern Dim) we see that it is
even going direction to VB habits.

However in my idea is it not the language that makes VB strong, it is the
way as it can be used in Visual Studio. Where the speed of creating
assemblies with VB is far superior to C#.

You also know how careful Microsoft is with code breaking changes after VB6
to Net.

Cor

"Herfried K. Wagner [MVP]" <hi***************@gmx.atschreef in bericht
news:us**************@TK2MSFTNGP02.phx.gbl...
"Scott M." <sm**@nospam.nospamschrieb:
>>Well, one could say that even VB.NET is only contained in VS to make it
easier for the VB Classic people to acommodate to the managed world.

One could also say that all programming languages exist to make it easier
for people who don't understand binary code to write programming
instructions, but how does that statement have any relevance to the point
that the legacy functions are largely a duplication of what's already in
the BCL?

VB is maybe a duplication of C# (the "#1 .NET programming language") which
exists only for compatibility purposes ;-).
>>Do you have the fear that VB would disappear from the .NET Framework?

I think that I've (and others) have made it clear that we do think that
portions of the VB language will dissapear, at some point, yes.

I have seen that for sure and I do not completely disagree because I know
how Microsoft values compatibility and "language stability". I, however,
do not share the pessimism about the future of a certain part of Visual
Basic without being pessimistic about the whole programming language.
Note that I am not pessimistic about VB's future, but I am not too
optimistic too.
>>I think avoiding to use the function is ad-hoc pessimism.

Ok. But, pessimism <bad thing. After all, have you ever used
pessimistic record locking? :)

;-)

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Jun 27 '08 #30

P: n/a
"Bill McCarthy" <Bi**@N0SPAM.comschrieb
>I believe that future releases of the Framework won't contain the
MSVB
functions anymore because they are not really necessary, but I think
this won't happen in the next 3-5 years.


I don't think this will happen at all. But, there are places such as
Silverlight, wehre a cut down set of functionality will require that
soem of the VB nicities aren't there.
We could make a bet and meet in 10 years. :-)
Imports VB= Microsoft.VisualBasic

Then I could write things like VB.Left(....), but I only do that when
I need VB.ChrW wide now days.
Ok, so we now have two precious functions: Msgbox and chrW. ;-)
Armin

Jun 27 '08 #31

P: n/a

"Armin Zingler" <az*******@freenet.dewrote in message
news:OQ**************@TK2MSFTNGP02.phx.gbl...
"Bill McCarthy" <Bi**@N0SPAM.comschrieb
>>I believe that future releases of the Framework won't contain the
MSVB
functions anymore because they are not really necessary, but I think
this won't happen in the next 3-5 years.


I don't think this will happen at all. But, there are places such as
Silverlight, wehre a cut down set of functionality will require that
soem of the VB nicities aren't there.

We could make a bet and meet in 10 years. :-)
>Imports VB= Microsoft.VisualBasic

Then I could write things like VB.Left(....), but I only do that when
I need VB.ChrW wide now days.

Ok, so we now have two precious functions: Msgbox and chrW. ;-)
LOL. I wasn't going to admit to using MsgBox ;)

Jun 27 '08 #32

P: n/a
Greg wrote:
I know I can use the Microsoft.VisualBasic.Left function to get the left
portion of a string, but I would prefer to avoid using any
Microsoft.VisualBasic namespace items. What is the equivilant in VB.Net
2005?
There's no Good Reason to throw them out completely (there are /still/
some things it really quite difficult to do /without/ them) but, given
the changes in things like indexing (zero or one-based), it may be
better to look for "purer" means.
Using Left:

Dim s2 as String = VB.Left( s1, 3 )

Using String.Substring:

If s1.Length >= 3 Then
s2 = s1.Substring( 0, 3 )
Else
s2 = String.Empty
End If

Note that Substring() is /far/ less tolerant of overrunning the end of
the source string ...

s1 = "ab"
s2 = s1.Substring( 0, 3 )

... gets you an ArgumentOutOfRangeException.

HTH,
Phill W.
Jun 27 '08 #33

This discussion thread is closed

Replies have been disabled for this discussion.