473,396 Members | 1,846 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,396 software developers and data experts.

Checking for A Blank String

I have an if statement that isn't working correctly and I was wondering how I
check for a blank string.
My Code Example

if me.fieldname(arrayIndex) = "" then
-----
end if

When I do this and there is no characters in the variable it does not enter
my IF statement like I would think it should. How do I properly check for a
blank variable?
Mar 9 '07 #1
42 2754
You might try using the string.IsNullOrEmpty method to test your
string for null or empty.

==============
Clay Burch
Syncfusion, Inc.
Mar 9 '07 #2
What you are doing is correct. A more VB way is to check the string against
String.Empty.

If it is not entering the if code then there is something other than "" or
String.Empty in the field.

Lloyd Sheen

"Playa" <Pl***@discussions.microsoft.comwrote in message
news:CB**********************************@microsof t.com...
>I have an if statement that isn't working correctly and I was wondering how
I
check for a blank string.
My Code Example

if me.fieldname(arrayIndex) = "" then
-----
end if

When I do this and there is no characters in the variable it does not
enter
my IF statement like I would think it should. How do I properly check for
a
blank variable?
Mar 9 '07 #3
On Mar 9, 10:45 am, Playa <P...@discussions.microsoft.comwrote:
I have an if statement that isn't working correctly and I was wondering how I
check for a blank string.
My Code Example

if me.fieldname(arrayIndex) = "" then
-----
end if

When I do this and there is no characters in the variable it does not enter
my IF statement like I would think it should. How do I properly check for a
blank variable?
How do I properly check for a blank variable?
Are you checking for a blank variable or blank string? If the former
use myVar is nothing the latter you should use
String.IsNullOrEmpty(myStringVar)

Thanks,

Seth Rowe

Mar 9 '07 #4
"Playa" <Pl***@discussions.microsoft.comschrieb:
>I have an if statement that isn't working correctly and I was wondering how
I
check for a blank string.
My Code Example

if me.fieldname(arrayIndex) = "" then
-----
end if

When I do this and there is no characters in the variable it does not
enter
my IF statement like I would think it should. How do I properly check for
a
blank variable?
If you want to check if your variable is not 'Nothing' and does not contain
an empty string:

\\\
If Len(s) 0 Then
...
End If
///

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

Mar 9 '07 #5
Herfried K. Wagner [MVP] wrote:
If you want to check if your variable is not 'Nothing' and does not
contain an empty string:

\\\
If Len(s) 0 Then
...
End If
///
This is my recommended way too. For all the new features and functionality
offered in .NET, I'll still go for good ol' Len() every time.
--

(O)enone
Mar 9 '07 #6
(O)enone wrote:
Herfried K. Wagner [MVP] wrote:
>If you want to check if your variable is not 'Nothing' and does not
contain an empty string:

\\\
If Len(s) 0 Then
...
End If
///

This is my recommended way too. For all the new features and functionality
offered in .NET, I'll still go for good ol' Len() every time.
The Len function is just a wrapper for the String.Length method.

If s.Length 0 Then
...
End If

--
Göran Andersson
_____
http://www.guffa.com
Mar 9 '07 #7
Göran,

"Göran Andersson" <gu***@guffa.comschrieb:
>>If you want to check if your variable is not 'Nothing' and does not
contain an empty string:

\\\
If Len(s) 0 Then
...
End If
///

This is my recommended way too. For all the new features and
functionality offered in .NET, I'll still go for good ol' Len() every
time.

The Len function is just a wrapper for the String.Length method.

If s.Length 0 Then
...
End If
No, it's more than that. It will return 0 if the value passed to it is
'Nothing'. The code you posted would throw a 'NullReferenceException' in
this case.

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

Mar 10 '07 #8
Herfried K. Wagner [MVP] wrote:
Göran,

"Göran Andersson" <gu***@guffa.comschrieb:
>>>If you want to check if your variable is not 'Nothing' and does not
contain an empty string:

\\\
If Len(s) 0 Then
...
End If
///

This is my recommended way too. For all the new features and
functionality offered in .NET, I'll still go for good ol' Len() every
time.

The Len function is just a wrapper for the String.Length method.

If s.Length 0 Then
...
End If

No, it's more than that. It will return 0 if the value passed to it is
'Nothing'. The code you posted would throw a 'NullReferenceException'
in this case.
Yes, ok, it's almost only a wrapper.

--
Göran Andersson
_____
http://www.guffa.com
Mar 10 '07 #9
Göran Andersson wrote:
Yes, ok, it's almost only a wrapper.
Perhaps, but the "almost" is the reason I choose to use it over the other
methods.

--

(O)enone
Mar 10 '07 #10
(O)enone wrote:
Göran Andersson wrote:
>Yes, ok, it's almost only a wrapper.

Perhaps, but the "almost" is the reason I choose to use it over the other
methods.
Why not use String.IsNullOrEmpty()? That is even more specialised for
this situation.

--
Göran Andersson
_____
http://www.guffa.com
Mar 10 '07 #11
"Göran Andersson" <gu***@guffa.comschrieb:
>>Yes, ok, it's almost only a wrapper.

Perhaps, but the "almost" is the reason I choose to use it over the other
methods.

Why not use String.IsNullOrEmpty()? That is even more specialised for this
situation.
Unfortunately this method will throw exceptions in certain scenarios and
it's much more to type and read. Why choose the compilated solution over
the simpler one?

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

Mar 10 '07 #12
Let me ask others to consider that "time-to-type" shouldn't be a major
consideration when developing applications. Yes if you are in a typing
contest but no if you are trying to write robust software for a living.

The reason one would choose a "complicated" solution if we honestly consider
typing IsNullOrEmpty complicated is to gain plainness and transparency.
There is nothing about a function named Len() which suggests that it is
testing for Null values and code which disguises what is happening is among
the worst kinds of code.

Using "plain", "simple", "obvious" and "easy-to-understand" as criteria let
each developer ask him/herself what does IsNullOrEmpty() test for and what
is it's return value. If you find it hard to figure out based upon it's
name then by all means choose Len().

I'd also be interested to know which "certain scenarios" throw exceptions I
didn't see it mentioned in the docs. Which exception does it throw?
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote...
"Göran Andersson" <gu***@guffa.comschrieb:
>>>Yes, ok, it's almost only a wrapper.

Perhaps, but the "almost" is the reason I choose to use it over the
other methods.

Why not use String.IsNullOrEmpty()? That is even more specialised for
this situation.

Unfortunately this method will throw exceptions in certain scenarios and
it's much more to type and read. Why choose the compilated solution over
the simpler one?

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

Mar 10 '07 #13
Tom,

"Tom Leylan" <tl*****@nospam.netschrieb:
Let me ask others to consider that "time-to-type" shouldn't be a major
consideration when developing applications. Yes if you are in a typing
contest but no if you are trying to write robust software for a living.
Why should using 'Len' be "less robust" (whatever that means)? The behavior
of 'Len' is well-known to anybody using BASIC for years and it's documented
too. Additionally, 'Len' is a 1st class citizen in VB. 'Len' feels much
more natural in VB than the "low-level" method 'IsNullOrEmpty', especially
because the term/keyword 'null' is not used in VB.
The reason one would choose a "complicated" solution if we honestly
consider typing IsNullOrEmpty complicated is to gain plainness and
transparency. There is nothing about a function named Len() which suggests
that it is testing for Null values and code which disguises what is
happening is among the worst kinds of code.
Well, that's the common behavior of almost all functions contained in the
'Strings' module.

Trying to avoid the use of VB's intrinsic functions is like trying to use a
screwdriver to screw in a nail although there is a hammer in the toolbox for
the reason that "a screwdriver is a more professional tool than a hammer."
Using "plain", "simple", "obvious" and "easy-to-understand" as criteria
let each developer ask him/herself what does IsNullOrEmpty() test for and
what is it's return value. If you find it hard to figure out based upon
it's name then by all means choose Len().
I doubt that any VB developer using the full repertoire available in the VB
"toolbox" will have problems to understand what 'Len' is doing. I also
believe that I can expect such knowledge from someone claming to know VB.
I'd also be interested to know which "certain scenarios" throw exceptions
I didn't see it mentioned in the docs. Which exception does it throw?
Read on here:

DANGER ! String.IsNullOrEmpty can lead to runtime Null exceptions !!
<URL:http://msmvps.com/blogs/bill/archive/2006/04/04/89234.aspx>

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

Mar 10 '07 #14
Herfried K. Wagner [MVP] wrote:
"Göran Andersson" <gu***@guffa.comschrieb:
>>>Yes, ok, it's almost only a wrapper.

Perhaps, but the "almost" is the reason I choose to use it over the
other methods.

Why not use String.IsNullOrEmpty()? That is even more specialised for
this situation.

Unfortunately this method will throw exceptions in certain scenarios
Can you give one single example where it would throw an exception?
and
it's much more to type and read. Why choose the compilated solution
over the simpler one?
I ask the same. When there is already a method available in the standard
libraries that does exactly what you want to do, why use another library
that has a wrapper for a different method that does half of what you
want to do?

--
Göran Andersson
_____
http://www.guffa.com
Mar 10 '07 #15
Herfried:

Each developer must ask him/herself a number of questions before making a
coding decision. If a person develops software by himself for use by a
small company with 25 employees the decisions made will differ from those of
a person who codes in a team of 25 developers that distributes the final
software to 3000 customer locations.

You can look up "robust" in a dictionary and I don't understand why you
didn't. I of course never wrote that the Len() function was "less robust"
but that trick can often work in a discussion so I admire your attempt.
Have you distributed your software to 3000 locations? When you found a bug
did you pick up the costs associated with redistribution? It should be
clear that "typing fast" isn't the issue but rather correctness, robustness,
verifiability, etc. are. These may not be as important if one is the
company "computer guru" and can walk over to secretary's machine to install
your new VB.Net utility but they are to many of us.

Software development (as I have found it) isn't about memorizing the
behavior of the functions in a particular language. If that were the most
important thing those of us who write software solutions wouldn't get much
done. I suggest it is only the MVP who knows what the 3rd parameter of
every multi-parameter function is and while that is an admirable feat it is
not my goal. My goal is to accept the contract to convert my app from
VB.Net to C# and to complete the task so I can get paid. My goal is to
re-engineer the Java app into VB.net and to complete the task so I can get
paid. My goal is not to save 7 characters when I type.

Null may not exist as a keyword but surely you aren't suggesting that VB
developers don't know the concept, right? So "nothing" is the keyword,
again I caution against memorization and vote in favor of learning concepts
rather than (or at least in addition to) syntax.

And of course it is nothing like using a screwdriver to hammer in a nail and
most definitely not due to some ranking of the tools in the toolbox. What
you are describing is the importance of using the hammer that is marked as
"VB.Net" and avoiding at all cost the hammer marked ".Net Framework". Your
special hammer is better than the hammer everybody else is using.
I doubt that any VB developer using the full repertoire available in the
VB "toolbox" will have problems to understand what 'Len' is doing. I also
believe that I can expect such knowledge from someone claming to know VB.
These particular doubts are unfounded. If you worked with software
developers for any length of time you will find that what they know varies
considerably. After you've looked up robust, take a moment to consider the
number of people posting questions here which on the surface seem trivial.
Many of these could be answered by checking the docs, a great number are
posted by working developers. You're making statements that have no basis
in fact in an attempt to "win" a discussion.

Again (for the record) generally when I reply to you it is not to enlighten
you as I expect only the VB-side of the story in your rebuttal but rather to
influence others who may wish to become more than a "VB programmer" and
aspire to becoming a software developer who uses VB. Furthermore I ask that
readers simply take note of your use of the terms harder, low-level and
complicated when something isn't VB and easy, fast, etc. when it is VB.
DANGER ! String.IsNullOrEmpty can lead to runtime Null exceptions !!
<URL:http://msmvps.com/blogs/bill/archive/2006/04/04/89234.aspx>
The link is appreciated. Now any reader with a concern can see plainly that
it does not in fact throw exceptions "in certain circumstances" but (if the
article is correct) will throw an exception in one particular case. The
author concludes "... in all fairness, this is actually a JIT optimization
problem that impacts both VB and C#" and a respondent claiming to be a
tester notes that "it most likely a bug on our side" and that they are
looking into it.

Let me let you in on something, there are bugs in the .Net Framework and
here is a secret, optimizers can make mistakes.

To other readers I'll suggest one avoid making rash coding decisions based
upon a bug. Work around the bug, it will be patched. Other bugs will turn
up in time, such is the life of a programmer. If there was never a bug in a
VB library then by all means limit your development to VB and never use
anything else (perhaps join the pro VB6 rant of at least one poster) because
you have truly found the one great solution.

For everybody else, raise your eyes and take a look out over the development
horizon. All tools are available to you including VB.Net of course.
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote...
Tom,

"Tom Leylan" <tl*****@nospam.netschrieb:
>Let me ask others to consider that "time-to-type" shouldn't be a major
consideration when developing applications. Yes if you are in a typing
contest but no if you are trying to write robust software for a living.

Why should using 'Len' be "less robust" (whatever that means)? The
behavior of 'Len' is well-known to anybody using BASIC for years and it's
documented too. Additionally, 'Len' is a 1st class citizen in VB. 'Len'
feels much more natural in VB than the "low-level" method 'IsNullOrEmpty',
especially because the term/keyword 'null' is not used in VB.
>The reason one would choose a "complicated" solution if we honestly
consider typing IsNullOrEmpty complicated is to gain plainness and
transparency. There is nothing about a function named Len() which
suggests that it is testing for Null values and code which disguises what
is happening is among the worst kinds of code.

Well, that's the common behavior of almost all functions contained in the
'Strings' module.

Trying to avoid the use of VB's intrinsic functions is like trying to use
a screwdriver to screw in a nail although there is a hammer in the toolbox
for the reason that "a screwdriver is a more professional tool than a
hammer."
>Using "plain", "simple", "obvious" and "easy-to-understand" as criteria
let each developer ask him/herself what does IsNullOrEmpty() test for and
what is it's return value. If you find it hard to figure out based upon
it's name then by all means choose Len().

I doubt that any VB developer using the full repertoire available in the
VB "toolbox" will have problems to understand what 'Len' is doing. I also
believe that I can expect such knowledge from someone claming to know VB.
>I'd also be interested to know which "certain scenarios" throw exceptions
I didn't see it mentioned in the docs. Which exception does it throw?

Read on here:

DANGER ! String.IsNullOrEmpty can lead to runtime Null exceptions !!
<URL:http://msmvps.com/blogs/bill/archive/2006/04/04/89234.aspx>

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

Mar 10 '07 #16
Herfried K. Wagner [MVP] wrote:
Why should using 'Len' be "less robust" (whatever that means)? The
behavior of 'Len' is well-known to anybody using BASIC for years and
it's documented too. Additionally, 'Len' is a 1st class citizen in VB.
'Len' feels much more natural in VB than the "low-level" method
'IsNullOrEmpty', especially because the term/keyword 'null' is not used
in VB.
We are now in VB.NET, not in VB6. What was is no longer. In .NET the
members of the System namespace is the first class citizens.
Trying to avoid the use of VB's intrinsic functions is like trying to
use a screwdriver to screw in a nail although there is a hammer in the
toolbox for the reason that "a screwdriver is a more professional tool
than a hammer."
That would be true if the .NET alternative was significantly less suited
for what you are trying to do.

In this case it's actually the opposite. The .NET alternative does
exactly what you want to do, while the VB6-like alternative returns a
value that has to be analysed to come to the same result.

--
Göran Andersson
_____
http://www.guffa.com
Mar 10 '07 #17
Tom,

"Tom Leylan" <tl*****@nospam.netschrieb:
You can look up "robust" in a dictionary and I don't understand why you
didn't.
I know the meaning of "robust". The whole discussion is now about using
'Len' vs. 'String.IsNullOrEmpty'. It's pretty clear that the shortest
solution is not always the most robust one. However, I do not see the
relation to my preference of 'Len'. 'Len' is faster to type and read and I
do not consider it less robust than 'String.IsNullOrEmpty'.
I of course never wrote that the Len() function was "less robust" but that
trick can often work in a discussion so I admire your attempt.
Well, then I suggest you specify more clearly what you are talking about.
Have you distributed your software to 3000 locations? When you found a
bug did you pick up the costs associated with redistribution?
Where's the relation to the topic?
It should be clear that "typing fast" isn't the issue but rather
correctness, robustness, verifiability, etc. are.
I consider both 'Len', 'String.IsNullOrEmpty' and 's IsNot Nothing AndAlso
s.Length 0' correct and robust solutions (lets forget the 'IsNullOrEmpty'
JITter bug here). So this calculus is not of much use here. That's why I
am using a different one: Ease of writing and reading.
Software development (as I have found it) isn't about memorizing the
behavior of the functions in a particular language. If that were the most
important thing those of us who write software solutions wouldn't get much
done.
Then I am wondering how you are writing code at all.
not my goal. My goal is to accept the contract to convert my app from
VB.Net to C# and to complete the task so I can get paid. My goal is to
re-engineer the Java app into VB.net and to complete the task so I can get
paid. My goal is not to save 7 characters when I type.
I believe anybody is free to use 'Len' or not. However, I do not see the
problem you are having with it. 'Len' can be converted to another
programming language as easily as 'String.IsNullOrEmpty'.
Null may not exist as a keyword but surely you aren't suggesting that VB
developers don't know the concept, right? So "nothing" is the keyword,
again I caution against memorization and vote in favor of learning
concepts rather than (or at least in addition to) syntax.
Hm... This point was intended as a joke. No, I really do /not/ think this
is a valid reason not to use 'String.IsNullOrEmpty', as I do not see the
naming and behavior as a reason for abandoning it from the toolbox.
And of course it is nothing like using a screwdriver to hammer in a nail
and most definitely not due to some ranking of the tools in the toolbox.
What you are describing is the importance of using the hammer that is
marked as "VB.Net" and avoiding at all cost the hammer marked ".Net
Framework". Your special hammer is better than the hammer everybody else
is using.
I gave the reasons why I prefer 'Len' over 'String.IsNullOrEmpty' in my
previous post. There is at least one technical reason that prevents me from
using 'String.IsNullOrEmpty'. My toolbox contains both the Visual Basic
Runtime Library and the .NET Framework Class Library and I do not have a
general (ideological) preference which tools to choose.
>I doubt that any VB developer using the full repertoire available in the
VB "toolbox" will have problems to understand what 'Len' is doing. I
also believe that I can expect such knowledge from someone claming to
know VB.

These particular doubts are unfounded. If you worked with software
developers for any length of time you will find that what they know varies
considerably. After you've looked up robust, take a moment to consider
the number of people posting questions here which on the surface seem
trivial. Many of these could be answered by checking the docs, a great
number are posted by working developers. You're making statements that
have no basis in fact in an attempt to "win" a discussion.
I do not want to win anything. It seems that you see discussions as fights
instead of what they are -- just discussions. Be assured that I know that
many developers don't have much knowledge about the tools they are using.
However, as I said, there is no problem 'Len' has and 'String.IsNullOrEmpty'
doesn't have.
Again (for the record) generally when I reply to you it is not to
enlighten you as I expect only the VB-side of the story in your rebuttal
but rather to influence others who may wish to become more than a "VB
programmer" and aspire to becoming a software developer who uses VB.
Furthermore I ask that readers simply take note of your use of the terms
harder, low-level and complicated when something isn't VB and easy, fast,
etc. when it is VB.
These points are all ungrounded prejudices, none of them apply. I am
actually using different programming languages and I prefer use the tools
they provide. The .NET Framework's method has been considered "low-level"
because the VB.NET class library and other libraries are built on top of the
..NET Framework's classes, often providing access on a higher level, as .NET
programming languages like VB.NET and C# do over IL.
>DANGER ! String.IsNullOrEmpty can lead to runtime Null exceptions !!
<URL:http://msmvps.com/blogs/bill/archive/2006/04/04/89234.aspx>

The link is appreciated. Now any reader with a concern can see plainly
that it does not in fact throw exceptions "in certain circumstances" but
(if the article is correct) will throw an exception in one particular
case.
At least to me as a non-native English speaker this means the same.
However, I only remembered that there was a problem with this method and I
didn't remember which one it was. I had to look for the article again to
see what it has been about (the JITter making problems with this method).
Let me let you in on something, there are bugs in the .Net Framework and
here is a secret, optimizers can make mistakes.

To other readers I'll suggest one avoid making rash coding decisions based
upon a bug. Work around the bug, it will be patched. Other bugs will
turn up in time, such is the life of a programmer. If there was never a
bug in a VB library then by all means limit your development to VB and
never use anything else (perhaps join the pro VB6 rant of at least one
poster) because you have truly found the one great solution.
If there are two ways to archieve a certain thing and one of them is faulty,
why choose the faulty one? It seems that your decisions are much more based
on ideology than mine. I use 'Len' because there are problems attached with
another way to archieve the same thing and you are wrongly extrapolating
that to a general preference of VB's functions over the .NET Framework.
For everybody else, raise your eyes and take a look out over the
development horizon. All tools are available to you including VB.Net of
course.
I 100 % agree, but this even includes using the tools VB provides over the
tools of the .NET Framework if their use has advantages.

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

Mar 10 '07 #18
Göran,

"Göran Andersson" <gu***@guffa.comschrieb:
>Why should using 'Len' be "less robust" (whatever that means)? The
behavior of 'Len' is well-known to anybody using BASIC for years and it's
documented too. Additionally, 'Len' is a 1st class citizen in VB. 'Len'
feels much more natural in VB than the "low-level" method
'IsNullOrEmpty', especially because the term/keyword 'null' is not used
in VB.

We are now in VB.NET, not in VB6. What was is no longer. In .NET the
members of the System namespace is the first class citizens.
Who's defining that? In VB.NET both the VB Runtime Library and the .NET
Framework Class Library are fist class citizens and there is no general rule
when to prefer one over the other.
>Trying to avoid the use of VB's intrinsic functions is like trying to use
a screwdriver to screw in a nail although there is a hammer in the
toolbox for the reason that "a screwdriver is a more professional tool
than a hammer."

That would be true if the .NET alternative was significantly less suited
for what you are trying to do.

In this case it's actually the opposite. The .NET alternative does exactly
what you want to do, while the VB6-like alternative returns a value that
has to be analysed to come to the same result.
Re-read my post. I gave a technical reason why I am preferring 'Len' in
this particular case.

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

Mar 10 '07 #19
Göran,

"Göran Andersson" <gu***@guffa.comschrieb:
>>>>Yes, ok, it's almost only a wrapper.

Perhaps, but the "almost" is the reason I choose to use it over the
other methods.

Why not use String.IsNullOrEmpty()? That is even more specialised for
this situation.

Unfortunately this method will throw exceptions in certain scenarios

Can you give one single example where it would throw an exception?
DANGER ! String.IsNullOrEmpty can lead to runtime Null exceptions !!
<URL:http://msmvps.com/blogs/bill/archive/2006/04/04/89234.aspx>
>and it's much more to type and read. Why choose the compilated solution
over the simpler one?

I ask the same. When there is already a method available in the standard
libraries that does exactly what you want to do, why use another library
that has a wrapper for a different method that does half of what you want
to do?
Because 'String.IsNullOrEmpty' can lead to potential problems at runtime. I
am not saying that 'String.IsNullOrEmpty' should never be used under all
circumstances.

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

Mar 10 '07 #20
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote...
I know the meaning of "robust". The whole discussion is now about using
'Len' vs. 'String.IsNullOrEmpty'. It's pretty clear that the shortest
solution is not always the most robust one. However, I do not see the
relation to my preference of 'Len'. 'Len' is faster to type and read and
I do not consider it less robust than 'String.IsNullOrEmpty'.
Okay but you wrote "whatever that means" and I can't read minds. This isn't
a discussion about Herfried's preferred syntax that is a given. If it was
available in VB6 Herfried prefers to use it in VB.Net. I understand that
along with your reasons I am addressing those who are on the fence. Those
who may not consider themselves VB gurus and who might one day like to
develop software (and be employable) in more than one language.
>I of course never wrote that the Len() function was "less robust" but
that trick can often work in a discussion so I admire your attempt.

Well, then I suggest you specify more clearly what you are talking about.
Got it... I'm to blame when you attempt to restate what I wrote and I'm to
blame when you write "Why should using 'Len' be "less robust" (whatever that
means)?" We've been through this before. You're playing a debate game if
you want to win the debate you win. I'm not debating with VB-gurus about
application development.
>Have you distributed your software to 3000 locations? When you found a
bug did you pick up the costs associated with redistribution?

Where's the relation to the topic?
What is being discussed is "preferences" and I'm trying to point out (and
you will to somebody else in another thread shortly I'm sure) one's
preferences are related to what one does. If you haven't worked in a large
group or haven't had to maintain a large project or haven't been responsible
for the distribution of large quantities of software your personal choices
are made based on a criteria which may not be shared.

To offer your own personal preference if it is based upon the experience of
working at home on small apps to somebody who is setting up team-based
coding standards without considering the impact is rude if nothing else.
Then I am wondering how you are writing code at all.
And I am wondering if you have ever worked as a software developer :-)
Hm... This point was intended as a joke. No, I really do /not/ think
this is a valid reason not to use 'String.IsNullOrEmpty', as I do not see
the naming and behavior as a reason for abandoning it from the toolbox.
In the words of Herfried: "Well, then I suggest you specify more clearly
what you are talking about."
I gave the reasons why I prefer 'Len' over 'String.IsNullOrEmpty' in my
previous post.
Actually what you did (and anybody can check it) is describe one solution as
"brilliant" and one as "stupid" using the well-worn screwdriver/hammer
analogy so as to avoid those words. Anybody can write "that's like..." and
proceed to make up something which it isn't like. Again you want to win the
debate rather than discuss the issue.
I do not want to win anything. It seems that you see discussions as
fights instead of what they are -- just discussions. Be assured that I
know that many developers don't have much knowledge about the tools they
are using. However, as I said, there is no problem 'Len' has and
'String.IsNullOrEmpty' doesn't have.
In the words of Herfried: "Well, then I suggest you specify more clearly
what you are talking about."

If it isn't a fight in your mind then why have you boiled the reasons down
to the length of the command? There isn't a command on Earth that I have
bemoaned typing due to my lack of time to type it or the pain and suffering
I incurred doing it.
These points are all ungrounded prejudices, none of them apply. I am
actually using different programming languages and I prefer use the tools
they provide. The .NET Framework's method has been considered "low-level"
because the VB.NET class library and other libraries are built on top of
the .NET Framework's classes, often providing access on a higher level, as
.NET programming languages like VB.NET and C# do over IL.
You have categorized them as "low-level" and perhaps a few others do but
that doesn't make them so.
At least to me as a non-native English speaker this means the same.
You understand the difference between buying (for instance) a Sony TV which
develops a problem and proclaiming "Sony TVs suck" and the statement "I
bought a Sony once and it had a problem."
If there are two ways to archieve a certain thing and one of them is
faulty, why choose the faulty one? It seems that your decisions are much
more based on ideology than mine. I use 'Len' because there are problems
attached with another way to archieve the same thing and you are wrongly
extrapolating that to a general preference of VB's functions over the .NET
Framework.
My decisions are based upon an ideology without a doubt. That ideology is
one that I have developed over the course of 30 years of software
development. It is not based upon the language I used or the length of a
command. When Clipper (a dBASE-language) introduced the radically changed
5.0 version I suggested that people make the switch because as radical as it
was it solved many of the nagging problems introduced by the dBASE language.
One's software would be safer, more robust, probably tighter and far less
ambiguous. On the other hand it would tend to less-well understood by dBASE
developers but better understood by Pascal and C developers and of course by
any Clipper developer who could see how much of an improvement the new
version was.

Without a rational ideology it's only about defending one's turf. I'll
suggest that is why the VB6 diehards feel threatened by everything and
anything that isn't VB6.
I 100 % agree, but this even includes using the tools VB provides over the
tools of the .NET Framework if their use has advantages.
Does the shop you work in use VB.Net exclusively? Is anything there written
in C#?

Mar 10 '07 #21
Herfried K. Wagner [MVP] wrote:
Göran,

"Göran Andersson" <gu***@guffa.comschrieb:
>>>>>Yes, ok, it's almost only a wrapper.
>
Perhaps, but the "almost" is the reason I choose to use it over the
other methods.

Why not use String.IsNullOrEmpty()? That is even more specialised
for this situation.

Unfortunately this method will throw exceptions in certain scenarios

Can you give one single example where it would throw an exception?

DANGER ! String.IsNullOrEmpty can lead to runtime Null exceptions !!
<URL:http://msmvps.com/blogs/bill/archive/2006/04/04/89234.aspx>
>>and it's much more to type and read. Why choose the compilated
solution over the simpler one?

I ask the same. When there is already a method available in the
standard libraries that does exactly what you want to do, why use
another library that has a wrapper for a different method that does
half of what you want to do?

Because 'String.IsNullOrEmpty' can lead to potential problems at
runtime. I am not saying that 'String.IsNullOrEmpty' should never be
used under all circumstances.
Have you tried the same using the Len method? The implementation of
IsNullOrEmpty and Len are quite similar, so I see no reason why the Len
method should not be subject to the same bug.

The fact that the bug was discovered using the IsNullOrEmpty method,
doesn't make that method any more problematic than any other method. You
are confusing the patient with the disease.

--
Göran Andersson
_____
http://www.guffa.com
Mar 10 '07 #22
Herfried K. Wagner [MVP] wrote:
>>Trying to avoid the use of VB's intrinsic functions is like trying to
use a screwdriver to screw in a nail although there is a hammer in
the toolbox for the reason that "a screwdriver is a more professional
tool than a hammer."

That would be true if the .NET alternative was significantly less
suited for what you are trying to do.

In this case it's actually the opposite. The .NET alternative does
exactly what you want to do, while the VB6-like alternative returns a
value that has to be analysed to come to the same result.

Re-read my post. I gave a technical reason why I am preferring 'Len' in
this particular case.
I have reread your post, and I can find no reason for such a misleading
analogy.

--
Göran Andersson
_____
http://www.guffa.com
Mar 10 '07 #23
Tom,

"Tom Leylan" <tl*****@nospam.netschrieb:
>I know the meaning of "robust". The whole discussion is now about using
'Len' vs. 'String.IsNullOrEmpty'. It's pretty clear that the shortest
solution is not always the most robust one. However, I do not see the
relation to my preference of 'Len'. 'Len' is faster to type and read and
I do not consider it less robust than 'String.IsNullOrEmpty'.

Okay but you wrote "whatever that means" and I can't read minds. This
isn't a discussion about Herfried's preferred syntax that is a given.
This is not a discussion about basing preferences on ideology. I have given
technical reasons why I avoid using 'String.IsNullOrEmpty' currently.
If it was available in VB6 Herfried prefers to use it in VB.Net.
Again, completely wrong. Although I am currently only active in the English
VB group, I use VB.NET, VB6, C#, and some other programming languages
equally. When using VB.NET, I use VB.NET, not only the .NET Framework, as I
do with other programming languages.
I understand that along with your reasons I am addressing those who
are on the fence. Those who may not consider themselves VB gurus
It's not me who would consider me a "VB guru" (I always hated this term
because it implies that somebody is inerrant).
and who might one day like to develop software (and be
employable) in more than one language.
Again I do not see the relation to the topic because nobody claims that
he/she "speaks" VB only.
>>Have you distributed your software to 3000 locations? When you found a
bug did you pick up the costs associated with redistribution?

Where's the relation to the topic?

What is being discussed is "preferences" and I'm trying to point out (and
you will to somebody else in another thread shortly I'm sure) one's
preferences are related to what one does. If you haven't worked in a
large group or haven't had to maintain a large project or haven't been
responsible for the distribution of large quantities of software your
personal choices are made based on a criteria which may not be shared.
Nobody is doubting that.
To offer your own personal preference if it is based upon the experience
of working at home on small apps to somebody who is setting up team-based
coding standards without considering the impact is rude if nothing else.
As I said already, I don't want to fight a battle here wo of us is the real
"guru", and as always I won't go down to the personal level. However, I
take my right to state and substantiate my preferences.
>Then I am wondering how you are writing code at all.

And I am wondering if you have ever worked as a software developer :-)
>Hm... This point was intended as a joke. No, I really do /not/ think
this is a valid reason not to use 'String.IsNullOrEmpty', as I do not see
the naming and behavior as a reason for abandoning it from the toolbox.

In the words of Herfried: "Well, then I suggest you specify more clearly
what you are talking about."
Tom, in contrast to you I do not blame you for making mistakes. Everybody
makes them, I make them and even you make them.
>I gave the reasons why I prefer 'Len' over 'String.IsNullOrEmpty' in my
previous post.

Actually what you did (and anybody can check it) is describe one solution
as "brilliant" and one as "stupid" using the well-worn screwdriver/hammer
analogy so as to avoid those words. Anybody can write "that's like..."
and proceed to make up something which it isn't like. Again you want to
win the debate rather than discuss the issue.
I wrote:

| Trying to avoid the use of VB's intrinsic functions is like trying to use
a
| screwdriver to screw in a nail although there is a hammer in the toolbox
for
| the reason that "a screwdriver is a more professional tool than a hammer."

I want to add "... VB's intrinsic functions for the sake of avoiding it...",
because it seems that this is not clear from reading my post.
>These points are all ungrounded prejudices, none of them apply. I am
actually using different programming languages and I prefer use the tools
they provide. The .NET Framework's method has been considered
"low-level" because the VB.NET class library and other libraries are
built on top of the .NET Framework's classes, often providing access on a
higher level, as .NET programming languages like VB.NET and C# do over
IL.

You have categorized them as "low-level" and perhaps a few others do but
that doesn't make them so.
It seems that you negatively connotate the term "low-level", which is not
what I do.
>At least to me as a non-native English speaker this means the same.

You understand the difference between buying (for instance) a Sony TV
which develops a problem and proclaiming "Sony TVs suck" and the statement
"I bought a Sony once and it had a problem."
Does that really matter here? If there are problems associated with the
function, regardless of their actual reason, why would I want to prefer it
over another method that doesn't suffer from the problem and has been used
for years?
>If there are two ways to archieve a certain thing and one of them is
faulty, why choose the faulty one? It seems that your decisions are much
more based on ideology than mine. I use 'Len' because there are problems
attached with another way to archieve the same thing and you are wrongly
extrapolating that to a general preference of VB's functions over the
.NET Framework.

My decisions are based upon an ideology without a doubt. That ideology is
one that I have developed over the course of 30 years of software
development. It is not based upon the language I used or the length of a
command. When Clipper (a dBASE-language) introduced the radically changed
5.0 version I suggested that people make the switch because as radical as
it was it solved many of the nagging problems introduced by the dBASE
language. One's software would be safer, more robust, probably tighter and
far less ambiguous. On the other hand it would tend to less-well
understood by dBASE developers but better understood by Pascal and C
developers and of course by any Clipper developer who could see how much
of an improvement the new version was.

Without a rational ideology it's only about defending one's turf. I'll
suggest that is why the VB6 diehards feel threatened by everything and
anything that isn't VB6.
That's another discussion, and I don't want to warm up the whole topic of
the migration problem again.
>I 100 % agree, but this even includes using the tools VB provides over
the tools of the .NET Framework if their use has advantages.

Does the shop you work in use VB.Net exclusively? Is anything there
written in C#?
I am currently working in another domain, not using .NET at all, but I would
not have a problem to do my work in C# if this was decided for a project.

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

Mar 11 '07 #24
Göran,

"Göran Andersson" <gu***@guffa.comschrieb:
>>>Perhaps, but the "almost" is the reason I choose to use it over the
other methods.

Why not use String.IsNullOrEmpty()? That is even more specialised for
this situation.

Unfortunately this method will throw exceptions in certain scenarios

Can you give one single example where it would throw an exception?
Here is a real-world sample:

\\\
Public Module Program
Public Sub Main()
Dim f As New Foo()
f.Test = Nothing
End Sub
End Module

Public Class Foo
Private m_Test As String

Public Property Test() As String
Get
Return m_Test
End Get
Set(ByVal Value As String)
If String.IsNullOrEmpty(Value) Then
Throw _
New ArgumentNullException( _
"The 'Value' must not be 'Nothing' or an empty
string." _
)
End If
m_Test = Value
End Set
End Property
End Class
///

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

Mar 11 '07 #25
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote...
This is not a discussion about basing preferences on ideology. I have
given technical reasons why I avoid using 'String.IsNullOrEmpty'
currently.
Yes and in this case you pointed out a bug. But how many other very similar
discussions have we had about the VB compatibility library?
> If it was available in VB6 Herfried prefers to use it in VB.Net.

Again, completely wrong. Although I am currently only active in the
English VB group, I use VB.NET, VB6, C#, and some other programming
languages equally. When using VB.NET, I use VB.NET, not only the .NET
Framework, as I do with other programming languages.
Completely wrong? It doesn't seem like that to me based upon your postings
covering some 5+ years. We've discussed topics in the VB6 newsgroup and now
in the VB.Net newsgroups but I don't recall reading or responding to any of
your posts on a C# newsgroup. Be that as it may I'm not stating that you
don't know another language I wrote quite plainly if you run into VB6 stuff
which is available in VB.Net you tend to choose the VB-compatible option.
>I understand that along with your reasons I am addressing those who
are on the fence. Those who may not consider themselves VB gurus
and who might one day like to develop software (and be
employable) in more than one language.

Again I do not see the relation to the topic because nobody claims that
he/she "speaks" VB only.
The topic is not the Len() function, it is simply the example that sparked
the thread. The reality is there are people reading these messages that are
just learning VB and those that can write code in another but are pretty
unlikely to write an entire application in say Java. I often address
message to those groups to get them to consider that other languages
implement constructs which can be of use the VB.Net developer. That if (for
instance) there was no linked list that one couldn't be written.
>In the words of Herfried: "Well, then I suggest you specify more clearly
what you are talking about."

Tom, in contrast to you I do not blame you for making mistakes. Everybody
makes them, I make them and even you make them.
I have never written "Well, then I suggest you specify more clearly what you
are talking about." to you or anybody else that I'm aware of with the
exception of my quoting you this time. Now you're contrasting me to the
person who wonders how I write software and suggests that I might learn to
write more clearly so they get their made up attributions correct.
I wrote:

| Trying to avoid the use of VB's intrinsic functions is like trying to
use a
| screwdriver to screw in a nail although there is a hammer in the toolbox
for
| the reason that "a screwdriver is a more professional tool than a
hammer."
Yes that's what you wrote. The .Net Framework is not "more professional"
any more than the Windows API is more professional. And you clearly wrote
"using a screwdriver to screw in a nail." So people who do it are in
essence "stupid" or are you now claiming that using a screwdriver to screw
in a nail is sometimes a reasonable solution? You aren't of course because
it isn't. If using the wrong tool is the same as using a "different" tool
it's time to go back to Logic 101.

Professionals often discuss various ways to solve a problem if somebody
posts "Yeah, or we could all just plink away on Amigas or something" (1) it
is an indication of their insincerity or lack of knowledge on the subject.

(1) from "Things to Say When You're Losing a Technical Argument"
It seems that you negatively connotate the term "low-level", which is not
what I do.
Calling functions in function library has never been considered low-level to
anyone I've known in the computer industry. But if you will agree we can
settle on Wikipedia's definition:
http://en.wikipedia.org/wiki/Low-lev...mming_language. How does
String.IsNullOrEmpty (or other Framework methods) fall into the context as
expressed there? Are they close to the hardware and do they provide little
or no abstraction from a computer's microprocessor? The answer as you will
find through a little diligence is no, of course not.

And here is a definition from Answers.com that seems even further from what
you claim low-level means.
http://www.answers.com/topic/low-level-language

Rather than my applying a negative connotation doesn't it appear more likely
that you misused the term "low-level" to make people think it was harder to
use the .Net Framework?
>You understand the difference between buying (for instance) a Sony TV
which develops a problem and proclaiming "Sony TVs suck" and the
statement "I bought a Sony once and it had a problem."

Does that really matter here? If there are problems associated with the
function, regardless of their actual reason, why would I want to prefer it
over another method that doesn't suffer from the problem and has been used
for years?
It only matters when you insist that your misapplication of the screwdriver
analogy along with your misuse of the term low-level combined with your
insistence that there are fewer letters to type in the function name Len()
matters. You can write "I hit that bug" if you in fact hit that bug and
everybody would consider that a heads-up warning. Alternatively you can
scour your friend's blogs for rarely encountered bugs to support your
position. One is real, one is artificial. If I post a bug report there is
every reason to believe another developer writing reasonable code would
encounter it as well. If I write "VB.Net sucks" because I encounter a bug
I'd appreciate it people just told me to keep my unsupportable opinions to
myself.
I am currently working in another domain, not using .NET at all, but I
would not have a problem to do my work in C# if this was decided for a
project.
In that case what would you do if you needed need to test if a string was
IsNullOrEmpty? There is a bug in the JIT optimizer you know?

Mar 11 '07 #26
Tom --

"Tom Leylan" <tl*****@nospam.netschrieb:
>This is not a discussion about basing preferences on ideology. I have
given technical reasons why I avoid using 'String.IsNullOrEmpty'
currently.

Yes and in this case you pointed out a bug. But how many other very
similar discussions have we had about the VB compatibility library?
I do not specifically remember any discussions, but I believe that
"Microsoft.VisualBasic.dll" is a good (stable, handy, ...) library. On the
other hand, I'd not use the compatibility libraries.
>> If it was available in VB6 Herfried prefers to use it in VB.Net.

Again, completely wrong. Although I am currently only active in the
English VB group, I use VB.NET, VB6, C#, and some other programming
languages equally. When using VB.NET, I use VB.NET, not only the .NET
Framework, as I do with other programming languages.

Completely wrong? It doesn't seem like that to me based upon your
postings covering some 5+ years. We've discussed topics in the VB6
newsgroup and now in the VB.Net newsgroups but I don't recall reading or
responding to any of your posts on a C# newsgroup.
I have never been "active" in an English-speaking VB6 newsgroup (except in
X-posts). Being a native German speaker I am mostly active in the German
..NET (VB.NET, C#, .NET, VS) and VB6 groups. Maybe you are mixing me up with
someone else?
wrote quite plainly if you run into VB6 stuff which is available in VB.Net
you tend to choose the VB-compatible option.
If this is the opposite to "using the .NET Framework only and trying to
avoid using the VB Runtime Library", then that's true.
>It seems that you negatively connotate the term "low-level", which is not
what I do.

Calling functions in function library has never been considered low-level
to anyone I've known in the computer industry.
That's not what I consider low-level too. However, the link you posted
http://en.wikipedia.org/wiki/Low-lev...mming_language.
is about programming languages. I am talking about libraries and I conform
with the definition given in <URL:http://en.wikipedia.org/wiki/Low-level>.
A "wrapper" /can/ be more high-level than the functionality it wraps, but
this is /not necessarily/ the case.
Rather than my applying a negative connotation doesn't it appear more
likely that you misused the term "low-level" to make people think it was
harder to use the .Net Framework?
No, I didn't. I just wanted to say that parts of the .NET Framework provide
full functionality, but in reality a simplified form is commonly requested
and thus a wrapper can be more "high-level".
>>You understand the difference between buying (for instance) a Sony TV
which develops a problem and proclaiming "Sony TVs suck" and the
statement "I bought a Sony once and it had a problem."

Does that really matter here? If there are problems associated with the
function, regardless of their actual reason, why would I want to prefer
it over another method that doesn't suffer from the problem and has been
used for years?

It only matters when you insist that your misapplication of the
screwdriver analogy along with your misuse of the term low-level combined
with your insistence that there are fewer letters to type in the function
name Len() matters. You can write "I hit that bug" if you in fact hit
that bug and everybody would consider that a heads-up warning.
Alternatively you can scour your friend's blogs for rarely encountered
bugs to support your position. One is real, one is artificial.
Take a look at my reply to Göran showing a typical scenario in which the
problem occurs ( <URL:news:OD**************@TK2MSFTNGP04.phx.gbl> ).
>I am currently working in another domain, not using .NET at all, but I
would not have a problem to do my work in C# if this was decided for a
project.

In that case what would you do if you needed need to test if a string was
IsNullOrEmpty? There is a bug in the JIT optimizer you know?
I'd use something not affected by the bug. My tests showed that it does not
occur when using 'Len' instead of 'IsNullOrEmpty' and that Len' provides a
semantically similar replacement. In C# I'd continue to write 'if (s ==
null || s.Length == 0)'.

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

Mar 11 '07 #27
Tut, tut ... I'm surprised at you Herfried.

That is a spurious example, and, quite frankly, an insult to our
intelligence.

The call to String.IsNullOrEmpty is NOT throwing any exception.

The exception is being thrown by the Set accessor of property Foo.Test when
the result of the call to String.IsNullOrEmpty is True.
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:OD**************@TK2MSFTNGP04.phx.gbl...
Göran,

"Göran Andersson" <gu***@guffa.comschrieb:
>>>>Perhaps, but the "almost" is the reason I choose to use it over the
other methods.

Why not use String.IsNullOrEmpty()? That is even more specialised for
this situation.

Unfortunately this method will throw exceptions in certain scenarios

Can you give one single example where it would throw an exception?

Here is a real-world sample:

\\\
Public Module Program
Public Sub Main()
Dim f As New Foo()
f.Test = Nothing
End Sub
End Module

Public Class Foo
Private m_Test As String

Public Property Test() As String
Get
Return m_Test
End Get
Set(ByVal Value As String)
If String.IsNullOrEmpty(Value) Then
Throw _
New ArgumentNullException( _
"The 'Value' must not be 'Nothing' or an empty
string." _
)
End If
m_Test = Value
End Set
End Property
End Class
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Mar 11 '07 #28
Stephany,

"Stephany Young" <noone@localhostschrieb:
Tut, tut ... I'm surprised at you Herfried.

That is a spurious example, and, quite frankly, an insult to our
intelligence.

The call to String.IsNullOrEmpty is NOT throwing any exception.

The exception is being thrown by the Set accessor of property Foo.Test
when the result of the call to String.IsNullOrEmpty is True.
You are right, I should really take more sleep. My bad and my excuses
(especially to Göran and Tom!). I have played around a little bit and I
could not come up with a useful example (which does not mean that such
examples do not exist). The problem seems to occur if the value of the
variable that is checked does not change and a loop is involved.

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

Mar 11 '07 #29
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote...
I have never been "active" in an English-speaking VB6 newsgroup (except in
X-posts). Being a native German speaker I am mostly active in the German
.NET (VB.NET, C#, .NET, VS) and VB6 groups. Maybe you are mixing me up
with someone else?
No I was mistaken about the group. A quick scan of the archives located the
arguments between you and Fergus Cooney in 2003. I also believed it was
longer ago so perhaps it wasn't 5+ years after all.
>wrote quite plainly if you run into VB6 stuff which is available in
VB.Net
you tend to choose the VB-compatible option.

That's not what I consider low-level too. However, the link you posted
>http://en.wikipedia.org/wiki/Low-lev...mming_language.
is about programming languages.
Which last time I checked VB.Net is...
I am talking about libraries and I conform with the definition given in
<URL:http://en.wikipedia.org/wiki/Low-level>. A "wrapper" /can/ be more
high-level than the functionality it wraps, but this is /not necessarily/
the case.
So you're opting for the page that has the following examples:

<begin quote>
Climate is a high level description of the actions of the atmosphere and
oceans. Physics of water and gas molecules is a low level description of the
same system.

The instruction "write a creative poem on love" is a high level instruction.
The instruction "tighten the tendons in the right wrist to grip the pen" is
a low level description of an activity within that.

"Wikipedia is an encyclopedia" is a high level description compared to
"Wikipedia is a collection of textual articles on many topics". The former
reflects a higher level view of organization, purpose, concept and
structure, but does not explain what Wikipedia physically is. The latter is
more detailed as to what exactly Wikipedia contains and how it's made up,
but doesn't explain what its overall purpose and goals are. These are
typical features of high and low level descriptions.

<end quote>

As a guy named Herfried once wrote: "What's the relation to the topic?"
No, I didn't. I just wanted to say that parts of the .NET Framework
provide full functionality, but in reality a simplified form is commonly
requested and thus a wrapper can be more "high-level".
I'll ask the rest of the reading public.... is Class.Method() syntax
considered lower-level than Len( parameter ) syntax? And secondly is
avoiding the supposed lower-level syntax the goal? Would the VB.Net
developer like to see wrappers for more of the .Net library to help hide the
gory details of the classes?
Take a look at my reply to Göran showing a typical scenario in which the
problem occurs ( <URL:news:OD**************@TK2MSFTNGP04.phx.gbl> ).
Well let's let that example die a peaceful death... :-)
I'd use something not affected by the bug. My tests showed that it does
not occur when using 'Len' instead of 'IsNullOrEmpty' and that Len'
provides a semantically similar replacement. In C# I'd continue to write
'if (s == null || s.Length == 0)'.
If I thought I'd be affected by what seems to be an odd bug I'd tend to
write a function named StringIsNullOrEmpty() which performed the necessary
checks returning a boolean value. That way (when the patch was finally
made) I would only have to globally search for my function and replace it
with a dot in the name. Similarly I could scan any existing code and
replace any I found with a dot in them to my replacement function.

I would rather instruct a programming team to use my replacement function
rather than a sequence of instructions they could conceivably type in
incorrectly (or just differently) somewhere.


Mar 11 '07 #30
Playa.

Now you have all the answers for an empty string, here the answer for a
blank string.

If myString.Indexoff(" ") <-1 then
'There are other characters than blanks in my string.
End if

If you mean an assigned string with no characters in it, than as made as
agreed answer from this newsgroup (after long investigations) by the long
time regulars in this newsgroup, we prefer:

If myString = ""

Try to avoid the = nothing, (or wrapped methods from that, because those
give back as well non assigned strings (for what the command to find only
those is myString Is Nothing).

Cor

"Playa" <Pl***@discussions.microsoft.comschreef in bericht
news:CB**********************************@microsof t.com...
>I have an if statement that isn't working correctly and I was wondering how
I
check for a blank string.
My Code Example

if me.fieldname(arrayIndex) = "" then
-----
end if

When I do this and there is no characters in the variable it does not
enter
my IF statement like I would think it should. How do I properly check for
a
blank variable?

Mar 11 '07 #31
Stephany,

I find your reaction overdone, there is in my opinion not any need to attack
Herfried personal on a code error. Just telling is for a guy as Herfried (or
me) more than enough to feel unhappy.

Cor
"Stephany Young" <noone@localhostschreef in bericht
news:us**************@TK2MSFTNGP03.phx.gbl...
Tut, tut ... I'm surprised at you Herfried.

That is a spurious example, and, quite frankly, an insult to our
intelligence.

The call to String.IsNullOrEmpty is NOT throwing any exception.

The exception is being thrown by the Set accessor of property Foo.Test
when the result of the call to String.IsNullOrEmpty is True.
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:OD**************@TK2MSFTNGP04.phx.gbl...
>Göran,

"Göran Andersson" <gu***@guffa.comschrieb:
>>>>>Perhaps, but the "almost" is the reason I choose to use it over the
>other methods.
>
Why not use String.IsNullOrEmpty()? That is even more specialised for
this situation.

Unfortunately this method will throw exceptions in certain scenarios

Can you give one single example where it would throw an exception?

Here is a real-world sample:

\\\
Public Module Program
Public Sub Main()
Dim f As New Foo()
f.Test = Nothing
End Sub
End Module

Public Class Foo
Private m_Test As String

Public Property Test() As String
Get
Return m_Test
End Get
Set(ByVal Value As String)
If String.IsNullOrEmpty(Value) Then
Throw _
New ArgumentNullException( _
"The 'Value' must not be 'Nothing' or an empty
string." _
)
End If
m_Test = Value
End Set
End Property
End Class
///

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

Mar 11 '07 #32
Herfried,

In my opinion absolute no need for an excuse. If you would not have done it,
I would have done it.

There are better methods than using legacy "C" code which I see so often
showed by C# guys, which is in my eyes as well very inefficient.

Cor

"Herfried K. Wagner [MVP]" <hi***************@gmx.atschreef in bericht
news:e7*************@TK2MSFTNGP03.phx.gbl...
Stephany,

"Stephany Young" <noone@localhostschrieb:
>Tut, tut ... I'm surprised at you Herfried.

That is a spurious example, and, quite frankly, an insult to our
intelligence.

The call to String.IsNullOrEmpty is NOT throwing any exception.

The exception is being thrown by the Set accessor of property Foo.Test
when the result of the call to String.IsNullOrEmpty is True.

You are right, I should really take more sleep. My bad and my excuses
(especially to Göran and Tom!). I have played around a little bit and I
could not come up with a useful example (which does not mean that such
examples do not exist). The problem seems to occur if the value of the
variable that is checked does not change and a loop is involved.

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

Mar 11 '07 #33
Goran,

You are consequently using legacy by the time standarized C code in this
newsgroup and tell than that it is Net.

It is in the namespace Net. That does not mean that solely that is Net code.
Every part of code in the different frameworks is Net. Including the ones in
the Visual Basic Namespaces and the other newer ones comming.

In my opinion there is better code, not the legacy C as well not the legacy
VBclassics, altough I will never tell anybody not to use it, there can be
endless reasons for that.

Cor

"Göran Andersson" <gu***@guffa.comschreef in bericht
news:en*************@TK2MSFTNGP06.phx.gbl...
Herfried K. Wagner [MVP] wrote:
>Why should using 'Len' be "less robust" (whatever that means)? The
behavior of 'Len' is well-known to anybody using BASIC for years and it's
documented too. Additionally, 'Len' is a 1st class citizen in VB. 'Len'
feels much more natural in VB than the "low-level" method
'IsNullOrEmpty', especially because the term/keyword 'null' is not used
in VB.

We are now in VB.NET, not in VB6. What was is no longer. In .NET the
members of the System namespace is the first class citizens.
>Trying to avoid the use of VB's intrinsic functions is like trying to use
a screwdriver to screw in a nail although there is a hammer in the
toolbox for the reason that "a screwdriver is a more professional tool
than a hammer."

That would be true if the .NET alternative was significantly less suited
for what you are trying to do.

In this case it's actually the opposite. The .NET alternative does exactly
what you want to do, while the VB6-like alternative returns a value that
has to be analysed to come to the same result.

--
Göran Andersson
_____
http://www.guffa.com

Mar 11 '07 #34
Playa:

I'd be suspicious of the answers you receive from people who repeatedly post
code they have never bothered to test. A few folks do this on a regular
basis, their code never works I believe "they just couldn't bother" pretty
much sums up the attitude.

Dim s1 As String = " "

Debug.WriteLine("this tests a blank string")

If s1.IndexOf(" ") <-1 Then
Debug.WriteLine("There are other characters than blanks in my
string")
End If

And the long-time regular developers typically prefer language-agnostic .Net
Framework syntax. Surely there should be a functional equivalent of the
IndexOf() method if function calls are the solution of the future. Perhaps
one will be added in the next version of VB?

My advice is never listen to somebody who can't post 3 lines of VB code that
actually does what they claim.
"Cor Ligthert [MVP]" <no************@planet.nlwrote...
Playa.

Now you have all the answers for an empty string, here the answer for a
blank string.

If myString.Indexoff(" ") <-1 then
'There are other characters than blanks in my string.
End if

If you mean an assigned string with no characters in it, than as made as
agreed answer from this newsgroup (after long investigations) by the long
time regulars in this newsgroup, we prefer:

If myString = ""

Try to avoid the = nothing, (or wrapped methods from that, because those
give back as well non assigned strings (for what the command to find only
those is myString Is Nothing).

Cor

Mar 11 '07 #35
"Cor Ligthert [MVP]" <no************@planet.nlwrote...
Herfried,

In my opinion absolute no need for an excuse. If you would not have done
it, I would have done it.
No doubt you would have posted it precisely because it didn't demonstrate
the bug. Herfried noticed his error immediately and basically said "oops" I
think it is reasonable to assume you are too busy being offended that you
don't see it yet.
There are better methods than using legacy "C" code which I see so often
showed by C# guys, which is in my eyes as well very inefficient.

Cor
If you cut back on typing nonsense you might consider if the .Net String
class methods are legacy C code (which comes as a surprise to everybody)
that you just posted a non-working example using the .IndexOf() method.
It's VB.Net syntax only if you post it then?

Oh, I apologize also. In my other reply I wrote you probably didn't test
your 3 lines of code but I could be wrong.... it worked on your computer
right? Tell you what though if you stop calling people you don't know "C#
guys" I'll avoid calling you a VB hooligan.

As for inefficient... I think it's a safe bet you never tested your theory.
Mar 11 '07 #36
Hi all,

For those who don't understand, as me in the beginning. the long message
from Tom Leylan.

It is based on the fact that I wrote

"Indexoff" instead of "indexof".

I think that it is obviously that I wrote my sample direct in the message
and also obviously that with that there will be typos. I don't even apology
for that, it will happen more. About what Tom wrote, this are already to
many words for that.

Cor
Mar 11 '07 #37
"Cor Ligthert [MVP]" <no************@planet.nlwrote...
Hi all,

For those who don't understand, as me in the beginning. the long message
from Tom Leylan.

It is based on the fact that I wrote

"Indexoff" instead of "indexof".

I think that it is obviously that I wrote my sample direct in the message
and also obviously that with that there will be typos. I don't even
apology for that, it will happen more. About what Tom wrote, this are
already to many words for that.
There isn't an IndexOff method is there, so you meant IndexOf() right? And
your code doesn't work right? I want the original poster to realize that
when you wrote "here is the answer for a blank string" that it wouldn't
work.

If I posted code that didn't work what would you post? And when somebody
else suggests that VB developers would use the following syntax perhaps you
will think twice about calling it C legacy code or the person who posts it a
C# fanatic.

Debug.WriteLine("this tests a blank string")

If (s1.Trim().Length() <0) Then
Debug.WriteLine("There are other characters than blanks in my
string")
Else
Debug.WriteLine("There are no other characters than blanks in my
string")
End If

Cor learn something from the exchanges of the last week or so. The
newsgroup doesn't need a sheriff and you would likely not get the job. If
you like the person they can do no wrong if you don't they can do nothing
right.

Mar 11 '07 #38
Cor Ligthert [MVP] wrote:
Goran,

You are consequently using legacy by the time standarized C code in this
newsgroup and tell than that it is Net.
By that reasoning it's not even C code, and most C code isn't C code at
all. C was not the first programming language.

Also by that reasoning, the LEN function is not a VB function at all,
it's a BASIC function.

Do you wish to continue down that path of that reasoning?
It is in the namespace Net. That does not mean that solely that is Net code.
Of course it is. Would it not be .NET code becase there are other
languages that uses similar syntax?
Every part of code in the different frameworks is Net. Including the ones in
the Visual Basic Namespaces and the other newer ones comming.
Yes, the VB6-style functions in the Microsoft.VisualBasic library is
also .NET. They are not, however, part of the System namespace.

Can you stop arguing about single words, and perhaps focus on the issue?
In my opinion there is better code, not the legacy C as well not the legacy
VBclassics, altough I will never tell anybody not to use it, there can be
endless reasons for that.
What code? What are you talking about?
Cor

"Göran Andersson" <gu***@guffa.comschreef in bericht
news:en*************@TK2MSFTNGP06.phx.gbl...
>Herfried K. Wagner [MVP] wrote:
>>Why should using 'Len' be "less robust" (whatever that means)? The
behavior of 'Len' is well-known to anybody using BASIC for years and it's
documented too. Additionally, 'Len' is a 1st class citizen in VB. 'Len'
feels much more natural in VB than the "low-level" method
'IsNullOrEmpty', especially because the term/keyword 'null' is not used
in VB.
We are now in VB.NET, not in VB6. What was is no longer. In .NET the
members of the System namespace is the first class citizens.
>>Trying to avoid the use of VB's intrinsic functions is like trying to use
a screwdriver to screw in a nail although there is a hammer in the
toolbox for the reason that "a screwdriver is a more professional tool
than a hammer."
That would be true if the .NET alternative was significantly less suited
for what you are trying to do.

In this case it's actually the opposite. The .NET alternative does exactly
what you want to do, while the VB6-like alternative returns a value that
has to be analysed to come to the same result.

--
Göran Andersson
_____
http://www.guffa.com
--
Göran Andersson
_____
http://www.guffa.com
Mar 11 '07 #39
Cor Ligthert [MVP] wrote:
Playa.

Now you have all the answers for an empty string, here the answer for a
blank string.
Not at all. A blank string is the same as an empty string.
If myString.Indexoff(" ") <-1 then
'There are other characters than blanks in my string.
End if
Again, you are posting nonsense code.

The condition tests if there is a space character in the string, but the
comment inside the If statement claims that it tests if there are other
characters than spaces in the string.

Whether the string contains a space character or not doesn't say
anything about what other characters the string may contain.
If you mean an assigned string with no characters in it, than as made as
agreed answer from this newsgroup (after long investigations) by the long
time regulars in this newsgroup, we prefer:

If myString = ""

Try to avoid the = nothing, (or wrapped methods from that, because those
give back as well non assigned strings (for what the command to find only
those is myString Is Nothing).

Cor

"Playa" <Pl***@discussions.microsoft.comschreef in bericht
news:CB**********************************@microsof t.com...
>I have an if statement that isn't working correctly and I was wondering how
I
check for a blank string.
My Code Example

if me.fieldname(arrayIndex) = "" then
-----
end if

When I do this and there is no characters in the variable it does not
enter
my IF statement like I would think it should. How do I properly check for
a
blank variable?

--
Göran Andersson
_____
http://www.guffa.com
Mar 11 '07 #40
Goran,

Thanks for the lesson,

Cor

"Göran Andersson" <gu***@guffa.comschreef in bericht
news:OY**************@TK2MSFTNGP05.phx.gbl...
Cor Ligthert [MVP] wrote:
>Goran,

You are consequently using legacy by the time standarized C code in this
newsgroup and tell than that it is Net.

By that reasoning it's not even C code, and most C code isn't C code at
all. C was not the first programming language.

Also by that reasoning, the LEN function is not a VB function at all, it's
a BASIC function.

Do you wish to continue down that path of that reasoning?
>It is in the namespace Net. That does not mean that solely that is Net
code.

Of course it is. Would it not be .NET code becase there are other
languages that uses similar syntax?
>Every part of code in the different frameworks is Net. Including the ones
in the Visual Basic Namespaces and the other newer ones comming.

Yes, the VB6-style functions in the Microsoft.VisualBasic library is also
.NET. They are not, however, part of the System namespace.

Can you stop arguing about single words, and perhaps focus on the issue?
>In my opinion there is better code, not the legacy C as well not the
legacy VBclassics, altough I will never tell anybody not to use it, there
can be endless reasons for that.

What code? What are you talking about?
>Cor

"Göran Andersson" <gu***@guffa.comschreef in bericht
news:en*************@TK2MSFTNGP06.phx.gbl...
>>Herfried K. Wagner [MVP] wrote:
Why should using 'Len' be "less robust" (whatever that means)? The
behavior of 'Len' is well-known to anybody using BASIC for years and
it's documented too. Additionally, 'Len' is a 1st class citizen in VB.
'Len' feels much more natural in VB than the "low-level" method
'IsNullOrEmpty', especially because the term/keyword 'null' is not used
in VB.
We are now in VB.NET, not in VB6. What was is no longer. In .NET the
members of the System namespace is the first class citizens.

Trying to avoid the use of VB's intrinsic functions is like trying to
use a screwdriver to screw in a nail although there is a hammer in the
toolbox for the reason that "a screwdriver is a more professional tool
than a hammer."
That would be true if the .NET alternative was significantly less suited
for what you are trying to do.

In this case it's actually the opposite. The .NET alternative does
exactly what you want to do, while the VB6-like alternative returns a
value that has to be analysed to come to the same result.

--
Göran Andersson
_____
http://www.guffa.com

--
Göran Andersson
_____
http://www.guffa.com

Mar 12 '07 #41
For those who want to know what Goran wrote in a more correct way.

http://www.levenez.com/lang/history.html#03

Cor
Mar 12 '07 #42
Göran,

"Göran Andersson" <gu***@guffa.comschrieb:
>Now you have all the answers for an empty string, here the answer for a
blank string.

Not at all. A blank string is the same as an empty string.
" " can be seen as a "blank" string (consisting of blanks only) which is
not empty.

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

Mar 12 '07 #43

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Guy Robinson | last post by:
I have the code below which parses an expression string and creates tokens. Can anyone suggest the best of error checking for things like: Valid variable only obj.attribute -whitespace allowed...
5
by: Sue | last post by:
As soon as a character is entered in the first field of a new record, the number of records shown in the navigation buttons increases by 1 and the new record button becomes enabled. In the...
14
by: Kayle | last post by:
How should we check if the '\0' characters exists in the string as I am confused that some books mentioned that we have to check whether we need to make sure that we pass the...
12
by: Vicky | last post by:
What is the better way of checking blank string is it strvar.lenght > 0 or strvar == "" or something else Thnaks
4
by: Patient Guy | last post by:
Does anyone have any coding rules they follow when doing argument checking? When arguments fail during check, do you return from the call with an ambiguous return value, or do you throw...
10
by: Jerim79 | last post by:
I am working on form validation. I have a scheme that is working for me, except for 3 input fields. Zip, Phone, and Fax are the input fields. I want to do two tests. First I want to check to make...
6
by: Jeff | last post by:
Could someone tell me the easiest way to check a string of variable length to see if it consists of all blank characters? ....or perhaps more generally, to see if all of the characters are the...
7
by: elnoire | last post by:
Greetings! I've just started learning python, so this is probably one of those obvious questions newbies ask. Is there any way in python to check if a text file is blank? What I've tried to...
4
by: barmatt80 | last post by:
I have created an unbound form so that when users enter the information, there is a save button they have to click, checking to make sure a field(txtDocketNo) is not blank. For some reason I cannot...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.