As a general rule if you are testing something that requires multiple IF statements (more than 2 say), it is infinitely preferable to use the SELECT/CASE method. That may or may not be suitable in your case though as you didn't post the whole code ;)
To deal with 'multiple choice conditions' (like fredledingue's example) VBScript offers a very standard language construct found in most other languages too: the If ... Then ... ElseIf ... Then ... ElseIf ... Then ... Else ... End If sequence. There is no need for a long sequence of End Ifs if you use it properly.
The Select Case statement (like switch in other languages) is meant to compare one value against a number of alternatives.
If you like the "select case true" curiosity of VBScript so much, I challenge you:
Look at this code
whether the
WScript.Echo " Condition ('a' = sTest or 'b' = sTest) is true for '" + sTest + "'"
Hi ehvbs, my guess is that both approaches will not print " Condition ('a' = sTest or 'b' = sTest) is true for '" + sTest + "'" But, in case of the select case, it is much easier to determine. By the way, you stick to the use of '+' instead of '&' for strings (little bit confusing).
Bye !
Edited : After running , I see both methods the same response.
< Message edited by didorno -- 1/17/2006 7:54:42 AM >
I think you didn't guess for the ElseIf part of the question - you knew what to expect from the established semantic of this construct. Even Mr. Gates would have to define a new keyword like "ElseIfOr" or "CheckContinue" (a kind of reversed break) if he wanted to establish a new conditional statement that tests/executes further after a first match.
For the Select Case question I know from the Docs that
... If testexpression matches an expressionlist expression in more than one Case clause, only the statements following the first match are executed. ...
Therefore no guessing needed for the standard usage of Select Case. But there is no established convention, analogy or documented promise to base a prediction about the result of the creative use of Select Case True on - you have to guess (just for fun, I trust) and then to test if you want to use this trick with confidence.
ad "&"
I have no arguments for my usage of the "&" operator, only excuses:
(1) When I started programming (BASIC) there was just one operator "+"; when I learned Pascal, C and C++ - ditto. Learning that Perl and PHP want "." to concatenate strings was easy, not forgetting it when switching languages is more difficult. I couldn't feel much attraction to the idea to have two string concatenation operators in one language.
(2) When I red about "&" in the Docs I took the statement Forces string concatenation of two expressions. seriously. I understand this as: Instead of writing explicit casts like sFrs = "11" : nSec = 47 : sTxt = sFrs + CStr( nSec ) you may write shorter sTxt = sFrs & nSec without loosing the indication of the fact that something special happens here. That seemed a good idea, but wasn't compatible with using "&" for all concatenations.
(3) Then I read ... However, if only one expression is Null, that expression is treated as a zero-length string ("") when concatenated with the other expression. ... I really don't like "however" in the docs of a programming language. Checking the "+" Docs: ... If one or both expressions are Null expressions, result is Null.. Then I knew that I had to use "+" to concatenate strings. I can't risk to let concatenations with unexpected Null values pass thru silently.
Let's assume I have to generate form letters with a promise and a condition from a database not under my control and look at this code
and this output:
& I'll give you all my money, if & works. + I'll give you all my money, if & works. & I'll give you all my money + No promises - something wicked happened!
Hi Fredledingue,
as to what is faster, I haven't a clue. If I should guess, I'd assume the If construct is faster, because the Select Case is more complicated - it needs to handle lists after the Case keywords. But that is just speculation.
Yes, I think I may start using + for concatenation. I always knew it was available I just never took the time to understand its pros/cons. since the pros at least break even or potentially outweigh the cons imo, I think I'll start using it so I have one less thing to worry about when I switch back and forth between VBS and Python.
I noticed that in the Select Case True construct there is no non-conditional alternative. If none of the condition are met, the script skip the select-case.
With End If you can write a simple Else with no condition attached and used for everything that doesn't fit into the other conditions above.