TextBox

[Drew Leon]

How do I get a text box to clear itself when I switch from one tab to
another. The TextBox is poulated using selections from the tabs, but when I
switch to a different tab, the information in the textbox is still there.
--
Have a great day!
Drew Leon

[Hal Rosser]

"Drew Leon" <Dr******@discussions.microsoft.com> wrote in message
news:ED**********************************@microsof t.com...

How do I get a text box to clear itself when I switch from one tab to
another. The TextBox is poulated using selections from the tabs, but when I switch to a different tab, the information in the textbox is still there.
--
Have a great day!
Drew Leon

textbox1.text = ""

[CMM]

Or textbox1.text = String.Empty

not sure I heard somewhere that this improves performance... something
having to do with inline literals NOT being efficiently "interned" in the
string table. I dunno. But, in VB.Classic this was indeed true: 10 ""'s in
your code meant 10 empty strings and their size descriptor were put into the
Vtable of your EXE.... this was and is a little known fact.
"Hal Rosser" <hm******@bellsouth.net> wrote in message
news:g5***************@bignews3.bellsouth.net...

"Drew Leon" <Dr******@discussions.microsoft.com> wrote in message
news:ED**********************************@microsof t.com...

How do I get a text box to clear itself when I switch from one tab to
another. The TextBox is poulated using selections from the tabs, but when

I

switch to a different tab, the information in the textbox is still there.
--
Have a great day!
Drew Leon

textbox1.text = ""

[Hal Rosser]

"CMM" <cm*@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

Or textbox1.text = String.Empty

not sure I heard somewhere that this improves performance... something
having to do with inline literals NOT being efficiently "interned" in the
string table. I dunno. But, in VB.Classic this was indeed true: 10 ""'s in
your code meant 10 empty strings and their size descriptor were put into the Vtable of your EXE.... this was and is a little known fact.

Interesting - I would have thought ms would have 'in-lined' it either way in
the compile process.

[Cor Ligthert [MVP]]

>

Interesting - I would have thought ms would have 'in-lined' it either way
in
the compile process.

Hal it is, at end in the optimized code there is no difference. In this
newsgroup to clean a string, is after long and endless discussions, by most
of us including me chosen for "".

Cor

[Drew Leon]

Thank you Hal. I have been trying to research my own question for two days
now, with no avail. I just can't get it right. I guess this is these are the
Beginners "bumps in the road." Thanks again for your help. Have a great day!

"Hal Rosser" <hm******@bellsouth.net> wrote in message
news:%I******************@bignews1.bellsouth.net.. .

"CMM" <cm*@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

Or textbox1.text = String.Empty

not sure I heard somewhere that this improves performance... something
having to do with inline literals NOT being efficiently "interned" in the
string table. I dunno. But, in VB.Classic this was indeed true: 10 ""'s
in
your code meant 10 empty strings and their size descriptor were put into

the

Vtable of your EXE.... this was and is a little known fact.

Interesting - I would have thought ms would have 'in-lined' it either way
in
the compile process.

[CMM]

I have standardized on String.Empty because I use it it to ALWAYS initialize
a string. (Dim s As String = String.Empty). Try using s.Length on an
un-initialized string and you'd see why this is very good practice!

Obviously this is much better than having As String = "" in dozens sometimes
hundreds(!) of places in your code (each one creating a *new* object). So if
I use it in that in the Dim, why not use it everywhere else (like
comparisons)?

That's just my practice. :-)
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:ON*************@tk2msftngp13.phx.gbl...

Interesting - I would have thought ms would have 'in-lined' it either way
in
the compile process.

Hal it is, at end in the optimized code there is no difference. In this
newsgroup to clean a string, is after long and endless discussions, by
most of us including me chosen for "".

Cor

[Cor Ligthert [MVP]]

CMM,

It is not consistent with what we have spoken as standard in this newsgroup.

For me everybody can use as he wants.

:-)

Cor

[CMM]

It's easier to use "" ... and very intuitive too. I know. I have to catch
myself all the time too. However, is it a standard (with frequenters of this
"newsgroup") to *initialize* strings as well?
Dim s As String = ""

I started doing this as a general practice after discovering that (in .NET
1.1) if you passed a non-initialized string to certain ADO.NET methods it
would cause an exception (and elsewhere like using s.Length). IMHO if you
have a lot of these (Dim s As String = "")... (for instance, if you have big
business objects with lots of string fields)... it is very bad and
inneficient to use "" instead of the String.Empty constant (because of the
object references being created and (and discarded) with the former).

[Cor Ligthert [MVP]]

CMM

....

It's easier to use "" ... and very intuitive too. I know. I have to catch
myself all the time too. However, is it a standard (with frequenters of
this "newsgroup") to *initialize* strings as well?
Dim s As String = ""

This is C style behaviour because there is a warning thrown, it is the
standard here not to initialize aninthing with a value what is standard
done. (However it gives you now that impossible not true warning).

Dim s As String = "" gives more instructions than needed.

However a string is a strange thing in VBNet. It behaves as a value and at
the same time it is an object.

There is a difference between
String Is Nothing (Is a real empty string which can exist if it is not yet
used)
String = Nothing (This one catches IS Nothing and = "")

However there can be some situations where you want to know Is Nothing.

Cor

[CMM]

> However a string is a strange thing in VBNet. It behaves as a value and at

the same time it is an object.
Like a photon. :-)
This is C style behaviour because there is a warning thrown, it is the
standard here not to initialize aninthing with a value what is standard
done.
Well, I guess that's OK if you don't expect to call ANY member method of the
string (.ToLower, .StartsWith, .Length, etc.)...which would cause and
exception!... and you're VERY SURE any subroutines (yours, framework, 3rd
party, whatever) you pass the string to won't do it also (like ADO.NET...
which by the way will).

Bad bad bad design.... how does one become an MVP? (in jest) ;-)
There is a difference between String Is Nothing (Is a real empty string
which can exist if it is not yet used) String = Nothing (This one catches
IS Nothing and = "")
Yeah. That's only because the comparison operators for a string are
overloaded to treat <Nothing> as ""... it doesn't mean that the string
really is ""

Dim s As String
MsgBox(a.Length.ToString()) <--- Exception! Why doesn't it return 0? ha ha
ha jokes on you!
MsgBox(a.ToLower) '<--- Exception thrown... why oh why???

Obviously, I'm being facetious.
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:uG**************@TK2MSFTNGP15.phx.gbl... CMM
This is C style behaviour because there is a warning thrown, it is the
standard here not to initialize aninthing with a value what is standard
done. (However it gives you now that impossible not true warning).
However a string is a strange thing in VBNet. It behaves as a value and at
the same time it is an object.
Like a photon. :-)

However there can be some situations where you want to know Is Nothing.

Cor

[Armin Zingler]

"CMM" <cm*@nospam.com> schrieb

However a string is a strange thing in VBNet. It behaves as a
value and at the same time it is an object.
Like a photon. :-)

This is C style behaviour because there is a warning thrown, it is
the standard here not to initialize aninthing with a value what is
standard done.

Well, I guess that's OK if you don't expect to call ANY member
method of the string (.ToLower, .StartsWith, .Length, etc.)...which
would cause and exception!...

Why do you call it on 'Nothing'? I could swear you forgot an Else block
before.
and you're VERY SURE any subroutines (yours, framework, 3rd party,
whatever) you pass the string to won't do it also (like ADO.NET... which
by the way will).
With your own routines, you have to check for Nothing anyway and throw an
ArgumentNullException. On the other side, before passing a string variable
to a procedure that does not "like" Nothing, you have the same problem as
mentioned above: You forgot an Else block before.

Dim s As String
MsgBox(a.Length.ToString()) <--- Exception! Why doesn't it return 0? ha ha
ha jokes on you!
MsgBox(a.ToLower) '<--- Exception thrown... why oh why???

Obviously, I'm being facetious.

"Variable 'a' not declared". ;-)

:-) Often, something is serious, despite. ;-) The example shows very well,
why it is not necessary to initialize it with "" (or string.empty): You
should never do what you do in the example.
Armin

[CMM]

"Armin Zingler" <az*******@freenet.de> wrote in message
news:eS**************@TK2MSFTNGP11.phx.gbl...

With your own routines, you have to check for Nothing anyway and throw an
ArgumentNullException. On the other side, before passing a string variable
to a procedure that does not "like" Nothing, you have the same problem as
mentioned above: You forgot an Else block before.
Sometimes you have no idea if the procedure you're calling cares or not.
Instead of checking for a null string with a myriad of If/Else loops all
over the place.... why not just do the decent thing and initialize your
string???
"Variable 'a' not declared". ;-)

Doh! No intellisense in a newsreader window. Good eyes! But, you know what I
meant by the code.
And my code doesn't look like that.... it always looks like:
Dim s As String = String.Empty
Dim a As String = String.Empty

And, I also initialize arrays for similar reasons...
Dim ary As Integer() = {}

I highly recommend it.... and so does Visual Studio's Code Analyzer. Makes
for nice bug-free, easy-to-read code.

[Cor Ligthert [MVP]]

CMM,

A few messages and now you show already yourself what is against "standard
consistent writing conventions for programs"

I assume that you see what I mean (otherwise I will explain it deeper). All
(good) developers will (lucky enough) argument it and try to make things
better.

(It was not by accident that I started this discussions, a part of this text
was already in my first answer to Hall, however I thought let it first
evaluate itself a little bit and have stuffed that text than)

:-)

Cor

[CMM]

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:um****************@tk2msftngp13.phx.gbl...

CMM,

A few messages and now you show already yourself what is against "standard
consistent writing conventions for programs"
Sorry, I have no clue.

I assume that you see what I mean (otherwise I will explain it deeper).
All (good) developers will (lucky enough) argument it and try to make
things better.

(It was not by accident that I started this discussions, a part of this
text was already in my first answer to Hall, however I thought let it
first evaluate itself a little bit and have stuffed that text than)

Again, I'm clueless. I just find it surprising that some of you guys
espouse even RECOMMEND such amaturish (IMO) practices. I haven't truly
participated in ng's for years... I work in big teams and collaborate with
developers in other companies.... so I haven't felt the need until recently
(VS2005). I am truly horrified at what I'm seeing in the (this?) community.
It's like NONE of the lessons of the past have been learned and not even
hints from other development platforms taken seriously. "That's a C# thing,"
"that's a C++"...... NO man, that's good common sense!

I do enjoy debating with you... :-) please don't take anything I say wrong.
I see you've helped countless people in these forums.

[Armin Zingler]

"CMM" <cm*@nospam.com> schrieb

"Armin Zingler" <az*******@freenet.de> wrote in message
news:eS**************@TK2MSFTNGP11.phx.gbl...

With your own routines, you have to check for Nothing anyway and
throw an ArgumentNullException. On the other side, before passing
a string variable to a procedure that does not "like" Nothing, you
have the same problem as mentioned above: You forgot an Else block
before.

Sometimes you have no idea if the procedure you're calling cares or
not. Instead of checking for a null string with a myriad of If/Else
loops all over the place.... why not just do the decent thing and
initialize your string???

Sorry, but you don't get the point. Why do you *always* ("always" means: no
matter which code path the CPU will go in this procedure) initialize it with
""?

- If it will be "" always, use a constant.

- The other case is "not always". "Not always" means, you have different
cases. If you have different cases, you can set it to "" in one case and to
other values in other cases. You will *never* run into a
NullReferenceException after the If-Then block. If you do, you forgot the
Else block. In addition, why always set it to "" if it will be overweritten
in one of the cases anyway?

This is true for both, when using the variable in your own procedure as well
as when passing it to another procedure.

I've written pretty much VB.Net code meanwhile but never had to initialize a
string variable to "" ever.

"Variable 'a' not declared". ;-)

Doh! No intellisense in a newsreader window. Good eyes! But, you
know what I meant by the code.
And my code doesn't look like that.... it always looks like:
Dim s As String = String.Empty
Dim a As String = String.Empty

And, I also initialize arrays for similar reasons...
Dim ary As Integer() = {}

I highly recommend it.... and so does Visual Studio's Code Analyzer.
Makes for nice bug-free, easy-to-read code.

Initializing arrays this way doesn't make sense as well. If you will always
have an empty array, you don't really need one. If it will not
always be empty, you can create an empty array in one case and a
not-empty array in other cases.
Of course, for both (strings and arrays) there are exceptions, but *as a
rule* what you're doing doesn't make sense at all.
Armin

[Herfried K. Wagner [MVP]]

"CMM" <cm*@nospam.com> schrieb:

I have standardized on String.Empty because I use it it to ALWAYS
initialize a string. (Dim s As String = String.Empty). Try using s.Length
on an un-initialized string and you'd see why this is very good practice!
I keep them uninitialized and use 'Len' instead of 'String.Length'.
Obviously this is much better than having As String = "" in dozens
sometimes hundreds(!) of places in your code (each one creating a *new*
object). So if I use it in that in the Dim, why not use it everywhere else
(like comparisons)?

It doesn't actually create new objects. All occurances of the zero-length
string literal are pointing to the same string object in memory. For
reasons of readability I'd prefer '""' over 'String.Empty'.

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

[Herfried K. Wagner [MVP]]

"CMM" <cm*@nospam.com> schrieb:

It's easier to use "" ... and very intuitive too. I know. I have to catch
myself all the time too. However, is it a standard (with frequenters of
this "newsgroup") to *initialize* strings as well?
Dim s As String = ""
I believe this strongly depends on what you are doing.
a lot of these (Dim s As String = "")... (for instance, if you have big
business objects with lots of string fields)... it is very bad and
inneficient to use "" instead of the String.Empty constant (because of the
object references being created and (and discarded) with the former).

That's plain wrong. Both, '""' and 'String.Empty' are equally efficient.

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

[CMM]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:O$****************@TK2MSFTNGP11.phx.gbl...
<snip>

That's plain wrong. Both, '""' and 'String.Empty' are equally efficient.

I'm not an MSIL expert but everything I've read suggests that you're wrong.
The former uses "ldstr" to push an object reference and forces a scan in the
string table for a match. The latter uses "ldsfld" which simply references
an already existing static (no scan of the string table, no new object).

Granted the performance is not noticable in normal situations... but if you
have a tons of big entity objects with string properties I don't think its
fair to say they're both "equally efficient."