using RIGHT()

  • Thread starter Thread starter Harry Hudini
  • Start date Start date
H

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]
 
Harry said:
myvar=right(mytext,len(mytext)-1)
however, VS highlights RIGHT as being read only.
Any ideas ?
Click to expand...

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)
 
Harry Hudini said:
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 ?
Click to expand...

The easiest way would be

myvar = mytext.Substring(1);
 
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.
 
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
 
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!
 
Steven said:
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!
Click to expand...

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.
 
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



Steven said:
The VB functions are NOT deprecated. They are full .Net functions, just
Click to expand...
like any other parts of .Net. Please to not deprecate the VB language,
thank you!
 
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.
 
Steven said:
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.
Click to expand...

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.
 
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



Steven said:
I am not going to pursue this any further than to say that I am heartily
Click to expand...
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.
 
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
 
Back
Top