Solution to using Left/Right in Forms without qualifiers

[StrandElectric]

StrandElectric wrote :

DanS formulated the question :
For instance for the former left there is nothing easier
than

dim x = theString.Substring(0,1) 'Which means one
character starting at the first position, however it can
done in more ways.

But as soon as you know this and like Armin wrote are a
little bit familiar with Net programming, you do for the
former right

dim y = theString.Substring(TheString.Length-10, 10) 'the
last 10 positions.

Yeah, that's far more intuitive and a lot easier to code
than Right$(str,4).

[/sarcasm]

So, add the namespace alias and just do:

Dim y = VB.Right(str,4)

For crying out loud, you only have to do this inside of a
form - and honestly, should you even have this logic there?

I don't see why not....if I've got a form with a text box, and
clicking some button on the form runs some code that uses a
substring of that text in the textbox, where else would you
put that code ?

Right Dan. There are many business applications where a substring is a
meanigful part of the solution. Strikes me there is a kind of snobbery at
work here. A simple and logical solution cannot be the right one. It must
be elaborate in concept and if possible execution.

No, it's not snobbery - it's proper design. Yes, it's a little more work
up front, but it saves much time down the road in maintainablity and
extendability.

Thanks Tom for bearing with me! For the first time I feel *slightly*
persuaded. Only slightly, mind you! (but why's 'mid' different?..)

 

[Andrew Morton]

(but why's 'mid' different?..)

Because a Form doesn't have a Mid property.

 

[Tom Shelton]

StrandElectric has brought this to us :

StrandElectric wrote :

DanS formulated the question :
For instance for the former left there is nothing easier
than

dim x = theString.Substring(0,1) 'Which means one
character starting at the first position, however it can
done in more ways.

But as soon as you know this and like Armin wrote are a
little bit familiar with Net programming, you do for the
former right

dim y = theString.Substring(TheString.Length-10, 10) 'the
last 10 positions.

Yeah, that's far more intuitive and a lot easier to code
than Right$(str,4).

[/sarcasm]

So, add the namespace alias and just do:

Dim y = VB.Right(str,4)

For crying out loud, you only have to do this inside of a
form - and honestly, should you even have this logic there?

I don't see why not....if I've got a form with a text box, and
clicking some button on the form runs some code that uses a
substring of that text in the textbox, where else would you
put that code ?

Right Dan. There are many business applications where a substring is a
meanigful part of the solution. Strikes me there is a kind of snobbery at
work here. A simple and logical solution cannot be the right one. It must
be elaborate in concept and if possible execution.

No, it's not snobbery - it's proper design. Yes, it's a little more work
up front, but it saves much time down the road in maintainablity and
extendability.

-- Tom Shelton

Thanks Tom for bearing with me! For the first time I feel *slightly*
persuaded. Only slightly, mind you! (but why's 'mid' different?..)

Well they aren't any different as far as speration is concerned
But, if you asking again why you don't have to qualify Mid in a form -
it's been explained already. But, I'll try and explain it one more
time...

In a form, you are sitting in basically the namespace: MyApp.MyForm
That is your current context.

MyForm has a Left and Right property - which makes their fully
qualified names: MyApp.MyForm.Left and MyApp.MyForm.Right respectively.

So, when you are in a form and you type Right or Left, the compiler
searches the current namespace first for a match on that symbol. What
it finds is MyApp.MyForm.Left (or MyApp.MyForm.Right) - so it complains
that you aren't using it correctly. So, because of scope resolution
rules, you have to tell the compiler specifically that the Left/Right
you want is Microsoft.VisualBasic.Strings.Left/Right. You do that
either by fully qualifying the name, or using the namespace alias which
as been demonstrated in this thread.

Mid works because there is no MyApp.MyForm.Mid - so, when the compiler
doesn't find a match in the current namespace, it looks at the imported
namespaces - and wham, it finds a Match in
Microsoft.VisualBasic.Strings.Mid. So, because there is not conflict,
you don't have to qualify it.

Rember - you only have to qualify when there is a name resolution
conflict. In a console app or your own module or class, you wouldn't
have to qualify Left or Right - unless of course you introduce a
conflicting symbol by giving your class a Left or Right property

 

[StrandElectric]

Because a Form doesn't have a Mid property.

Thanks. Makes sense. But I still maintain that the language interface or
whatever you call it should be able to detect when the use of left or right
is in the context of splitting a string, and act accordingly. However, I' m
slightly *more* convinced by that succint answer (the kind I tend to be able
to understand (quaver!)).

 

[StrandElectric]

StrandElectric has brought this to us :

StrandElectric wrote :

DanS formulated the question :
For instance for the former left there is nothing easier
than

dim x = theString.Substring(0,1) 'Which means one
character starting at the first position, however it can
done in more ways.

But as soon as you know this and like Armin wrote are a
little bit familiar with Net programming, you do for the
former right

dim y = theString.Substring(TheString.Length-10, 10) 'the
last 10 positions.

Yeah, that's far more intuitive and a lot easier to code
than Right$(str,4).

[/sarcasm]

So, add the namespace alias and just do:

Dim y = VB.Right(str,4)

For crying out loud, you only have to do this inside of a
form - and honestly, should you even have this logic there?

I don't see why not....if I've got a form with a text box, and
clicking some button on the form runs some code that uses a
substring of that text in the textbox, where else would you
put that code ?

Right Dan. There are many business applications where a substring is a
meanigful part of the solution. Strikes me there is a kind of snobbery
at work here. A simple and logical solution cannot be the right one. It
must be elaborate in concept and if possible execution.

No, it's not snobbery - it's proper design. Yes, it's a little more
work up front, but it saves much time down the road in maintainablity
and extendability.

-- Tom Shelton

Thanks Tom for bearing with me! For the first time I feel *slightly*
persuaded. Only slightly, mind you! (but why's 'mid' different?..)

Well they aren't any different as far as speration is concerned But,
if you asking again why you don't have to qualify Mid in a form - it's
been explained already. But, I'll try and explain it one more time...

In a form, you are sitting in basically the namespace: MyApp.MyForm
That is your current context.

MyForm has a Left and Right property - which makes their fully qualified
names: MyApp.MyForm.Left and MyApp.MyForm.Right respectively.

So, when you are in a form and you type Right or Left, the compiler
searches the current namespace first for a match on that symbol. What it
finds is MyApp.MyForm.Left (or MyApp.MyForm.Right) - so it complains that
you aren't using it correctly. So, because of scope resolution rules, you
have to tell the compiler specifically that the Left/Right you want is
Microsoft.VisualBasic.Strings.Left/Right. You do that either by fully
qualifying the name, or using the namespace alias which as been
demonstrated in this thread.

Mid works because there is no MyApp.MyForm.Mid - so, when the compiler
doesn't find a match in the current namespace, it looks at the imported
namespaces - and wham, it finds a Match in
Microsoft.VisualBasic.Strings.Mid. So, because there is not conflict, you
don't have to qualify it.

Rember - you only have to qualify when there is a name resolution
conflict. In a console app or your own module or class, you wouldn't have
to qualify Left or Right - unless of course you introduce a conflicting
symbol by giving your class a Left or Right property

And...BINGO! He's done it folks. I am persuaded. I nearly understood that.
Thanks Tom for your great patience especially in the light of my growing
frustration leading to the 'snobbery' blast! Here's how I translate this:
vb.net is so much more flexible that sometimes we have to be more specific
(and therefore more aparently obscure) in coding lest the wrong option is
instigated. Right? If any of you have already been saying that in so many
different ways, I apologise.

OK, now for the next job. Defend the total lack of the ability to produce
proper formatted reports containing variables in a straightforward way? Or,
if you can't, please join me in condemning it's omission. It is needed in
practically every financial application. Funnily enough, althoguh vb6 will
do it readily and well, the vb6 books omitted it too!

 

[Cor]

I think I made my complete sample to show you that for nothing in this
message thread

Because of the actuality a slightly snipped and changed copy of that

Strand-,

I've showed you endless times that the Mid Right and Left still
exist.

I try to explain the situation about the Left and the Right and the
namespace, like Tom and Armin did before me.

Because the endless quantity of names have the designers of Net adepted the
idea of namespaces in fact nothing more than a levelled dictionary.

A problem is with the Windows Forms namespace is, that it contains windows
forms (and all controls) with the properties Right and Left.
It means that they have become ambiguous.
In a class is always used in that case the class donut (member) as default,
other use of names need to be fully qualified as that is called.

However, if you try this in a console application (you can try it in your
Visual Basic Express) then this code goes without any problem

Module Module1
Sub Main()
Console.WriteLine(Mid("Donut", 1, 2))
Console.WriteLine(Right("Donut", 3))
Console.WriteLine(Left("Donut", 2))
Console.ReadKey()
End Sub
End Module

So try that, it becomes clearer.

-Cor


"StrandElectric" wrote in message

Because a Form doesn't have a Mid property.

Thanks. Makes sense. But I still maintain that the language interface or
whatever you call it should be able to detect when the use of left or right
is in the context of splitting a string, and act accordingly. However, I' m
slightly *more* convinced by that succint answer (the kind I tend to be able
to understand (quaver!)).

 

[Tom Shelton]

DanS wrote on 1/21/2011 :

DanS was thinking very hard :

DanS brought next idea :

DanS formulated the question :
For instance for the former left there is nothing
easier than

dim x = theString.Substring(0,1) 'Which means one
character starting at the first position, however it
can done in more ways.

But as soon as you know this and like Armin wrote are
a little bit familiar with Net programming, you do
for the former right

dim y = theString.Substring(TheString.Length-10, 10)
'the last 10 positions.

Yeah, that's far more intuitive and a lot easier to
code than Right$(str,4).

[/sarcasm]

So, add the namespace alias and just do:

Dim y = VB.Right(str,4)

For crying out loud, you only have to do this inside of
a form - and honestly, should you even have this logic
there?

I don't see why not....if I've got a form with a text
box, and clicking some button on the form runs some
code that uses a substring of that text in the textbox,
where else would you put that code ?

In a class that implements the buisness logic.

The form is a class, therefore, it is already in the class
it needs to be in.

A form is a class that is true. But, it's responsibility
is displaying information - not processing. Separation of
concerns my friend....

Yes, well......if I was writing a complex application that
required modularity, for plugins or exposed an API, or
similar, I would do that.

I hear ya, I'm not a purist or anything... Except, I wouldn't do that
for just modularity and api support. It helps programs handle
change... For instance, suddenly my forms app needs to move to the
web... Ok, write a new interface, but I don't really need to change the
processsing logic. The nice thing is that using OOP concepts you can
really build a framework for this stuff once, and then reuse it over
and over without much effort

But, if your just writing throw away utilities, then that's cool.

 

[Cor]

Tom,

I write this kind of messages only on Friday eve, I thought you were still
in Friday midday currently, you got early home?

Oh yes Friday eve started here.

Cor

"Tom Shelton" wrote in message

DanS wrote on 1/21/2011 :

DanS was thinking very hard :

DanS brought next idea :
DanS formulated the question :
For instance for the former left there is nothing
easier than dim x = theString.Substring(0,1) 'Which means one
character starting at the first position, however it
can done in more ways.

But as soon as you know this and like Armin wrote are
a little bit familiar with Net programming, you do
for the former right dim y =
theString.Substring(TheString.Length-10, 10)
'the last 10 positions.

Yeah, that's far more intuitive and a lot easier to
code than Right$(str,4).

[/sarcasm]

So, add the namespace alias and just do:

Dim y = VB.Right(str,4)

For crying out loud, you only have to do this inside of
a form - and honestly, should you even have this logic
there?

I don't see why not....if I've got a form with a text
box, and clicking some button on the form runs some
code that uses a substring of that text in the textbox,
where else would you put that code ?

In a class that implements the buisness logic.

The form is a class, therefore, it is already in the class
it needs to be in.

A form is a class that is true. But, it's responsibility
is displaying information - not processing. Separation of
concerns my friend....

Yes, well......if I was writing a complex application that required
modularity, for plugins or exposed an API, or similar, I would do that.

I hear ya, I'm not a purist or anything... Except, I wouldn't do that
for just modularity and api support. It helps programs handle
change... For instance, suddenly my forms app needs to move to the
web... Ok, write a new interface, but I don't really need to change the
processsing logic. The nice thing is that using OOP concepts you can
really build a framework for this stuff once, and then reuse it over
and over without much effort

But, if your just writing throw away utilities, then that's cool.