using RIGHT()

[Harry Hudini]

Is there a reason why VS queries my use of the RIGHT function? I want to
remove the first character from a string, and im using the ever faithful
RIGHT function to do;

myvar=right(mytext,len(mytext)-1)

however, VS highlights RIGHT as being read only.

Any ideas ?

--
________________________________________________
ADSSupport.net
http://www.adssupport.net
Dedicated free Active Directory ServicesT support

email: oliver.marshall@[email protected]

 

[Gigio2k [work]]

myvar=right(mytext,len(mytext)-1)
however, VS highlights RIGHT as being read only.
Any ideas ?

use this features :
myvarString = myvarstrinf.remove(0,1)
( remove ( Start , lenght ) )

if you would use a Vb6 reference use this :
myVarString = STRINGS.RIGHT(mytext,Stings.lenght(mytext)-1)

 

[Jon Skeet [C# MVP]]

Is there a reason why VS queries my use of the RIGHT function? I want to
remove the first character from a string, and im using the ever faithful
RIGHT function to do;

myvar=right(mytext,len(mytext)-1)

however, VS highlights RIGHT as being read only.

Any ideas ?

The easiest way would be

myvar = mytext.Substring(1);

 

[Guest]

The reason that Right is highlighted as read-only is that Right is a read-only (integer) property of a form. In order to use the Right (string) function in a form, you must refer to it as 'Microsoft.VisualBasic.Right'. In a class or module you can use Right as you usually do.

 

[Rick Winscot]

Harry,

..NET still supports old VB6 functions via the VB6 namespace... however, I
would earnestly encourange you to make an effort to move away from old
coding practices and really get familiar with .NET. Who knows how long
these depricated functions will be available... and what the end result will
be for not letting go...

Rick Winscot
www.zyche.com

 

[Guest]

The VB functions are NOT deprecated. They are full .Net functions, just like any other parts of .Net. Please to not deprecate the VB language, thank you!

 

[Jon Skeet [C# MVP]]

The VB functions are NOT deprecated. They are full .Net functions,
just like any other parts of .Net. Please to not deprecate the VB
language, thank you!

No, they're *not* like any other parts of .NET. For instance, they're
only even *documented* if you include Visual Basic in your filter in
MSDN - they're documented in the Visual Basic reference, rather than
the .NET Framework reference. They're also less likely to be available
on non-MS versions of the CLR than other classes.

There's a good reason why they're in an assembly called
Microsoft.VisualBasic - they're there basically for support of VB
programmers, and weren't really intended for calling directly from
other languages. The same is *not* true of the rest of the framework.

 

[Ginny Caughey [MVP]]

Steven,

Of course the VB language is not deprecated! But I agree with Rick that
transitioning away from the compatibility VB runtime functions is a good
idea.

--
Ginny Caughey
..Net Compact Framework MVP

Have an opinion on the effectiveness of Microsoft Embedded newsgroups?
Let Microsoft know!
https://www.windowsembeddedeval.com/community/newsgroups

The VB functions are NOT deprecated. They are full .Net functions, just

like any other parts of .Net. Please to not deprecate the VB language,
thank you!

 

[Guest]

I am not going to pursue this any further than to say that I am heartily sick and tired of people treating VB as a second class language. Somehow, C# constructs are 'OK', but VB functions are 'deprecated'. When you deprecate my language, you deprecate me as a programmer, and I resent it.

 

[Jon Skeet [C# MVP]]

I am not going to pursue this any further than to say that I am
heartily sick and tired of people treating VB as a second class
language. Somehow, C# constructs are 'OK', but VB functions are
'deprecated'. When you deprecate my language, you deprecate me as a
programmer, and I resent it.

It's fine to say that the VB.NET functions are part of VB.NET. It's
*not* fine (IMO) to claim they have the same status as the rest of the
..NET framework, when it seems fairly clear to me that they don't.

Note that the difference here between C# and VB.NET is that C# doesn't
have any classes to support it (aside from the compiler and code DOM,
of course). It's a much smaller *language* because it just relies on
the framework to provide the "meat" of things. To me, that's a better
way round than to have loads of things built into the language. As
evidence of that, look how this thread started - because there's a
property which has the same name as a language function. The bigger the
language, the more likely that is to happen.

 

[Chris Tacke, eMVP]

It's not a deprecation of VB, it's a deprecation of procedural coding
practice. The VisualBasic namespace was included to make migration of VB6
code easier. I don't recall anyone saying C# constructs were good and VB
constructs are bad nor did anyone say that the language was deprecated. Di
dyou use line number in VB6? No, yet they were supported. Why weren't they
used? Because the idea was replaced with something better. The same holds
true here. Why cling to the VisualBasic.Right function instead of just
using String.SubString like every other .NET language, including COBOL and
Fortran? Without improvements the language *will* become deprecated, and
not maintaining code readability or interoperabilty for the sake of
developer comfort is ridiculous.

--
Chris Tacke, eMVP
Co-Founder and Advisory Board Member
www.OpenNETCF.org
---
---
Principal Partner
OpenNETCF Consulting
www.OpenNETCF.com

I am not going to pursue this any further than to say that I am heartily

sick and tired of people treating VB as a second class language. Somehow,
C# constructs are 'OK', but VB functions are 'deprecated'. When you
deprecate my language, you deprecate me as a programmer, and I resent it.

 

[Rick Winscot]

Wow... stir the pot get the horns! I'm smiling big as anything right now...
Perhaps I should share my definition of deprecated in order to clarify.

1. A deprecated item is one that has been outdated by newer constructs...
2. Deprecated items may* become obsolete in future versions or releases...
3. Available for upward compatability of existing applications but not
recommend to become the base for new applications.

In closing... Amen Chris... Amen.

Rick Winscot
www.zyche.com