Microsoft.VisualBasic.Left Function

  • Thread starter Thread starter Bill McCarthy
  • Start date Start date
Greg said:
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
 
Greg said:
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.
 
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
 
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
 
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
 
See my response to Herfried.


Cor Ligthert said:
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
 
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
 
Scott M. said:
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 ;)
 
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
 
Greg said:
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
 
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
 
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
 
In that case, use C# for their projects.

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
 
Scott M. said:
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.
 
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
 
Cor Ligthert said:
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.
 
Herfried K. Wagner said:
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

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.
 
Scott M. said:
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!
 
Herfried K. Wagner said:
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
 
Back
Top