I'm using an Or statement in my case expression.
Even though I have a value within this range, it didn't find a match. Why not?
Example Code:
Select Case 2
Case 0
' Some logic
Case 1
' Some other logic
Case 2 Or 3
Console.WriteLine("hit")
End Select
With the above I would assume that hit would be printed, but that's not the case.
Use the comma operator to delimit case statements
Select Case 2
Case 0,1,2,3
Console.WriteLine("hit")
End Select
As Jared said, you need to use the comma operator to delimit case statements.
The Or you were doing is a bitwise OR, resulting in it being "3". Amusingly, "2 AND 3" would probably have worked for your specific case.
JaredPar has it right but you can also use the To construct
Select Case 2
Case 0,1
Case 2 To 3
Console.WriteLine("Hit")
End Select
This would be 0 or 1 do nothing, 2 or 3 print Hit...The To construct is a range...
Edit: It appears I was wrong in assuming that VB.NET doesn't allow Case ORing. I was thinking in C# and IL and it appears I was wrong.
However, as someone pointed out, the reason your code did not work was because Case 2 Or 3 was evaluating 2 Or 3 as a bitwise or and hence evaluating to Case 3.
For clarification:
2 binary = 0000 0010
3 binary = 0000 0011
2 Or 3 binary = 0000 0011 (= 3)
Select Case 2
Case 0 '--> no match
Case 1 '--> no match
Case 2 Or 3 '(equivalent to Case 3 --> no match)
End Select
However, I feel that I should point out that for the sake of performance, one should not use such constructs. When the compiler encounters Select statements (switch in C#) it will try to compile them using lookup tables and the switch MSIL instruction but in the case where you have something like Case 1,2,11,55 the compiler will not be able to convert that to a lookup table and it will have to use a series of compares (which is like using If.. Else).
The point is that in order to really take advantage of the Select statement, the cases should be designed with that in mind. Otherwise, the only benefit is code readability.
A well designed switch is an O(1) operation whereas an poorly designed one (which is equivalent to a series of If..Then..Else statements) is an O(n) operation.
This will allow you to perform "something" in the case of 0, "something else" in the case of 1, "hit" in the case of 2 or 3 or "hit else" otherwise.
Select Case 2
Case 0
Console.WriteLine("something")
Case 1
Console.WriteLine("something else")
Case Is 2 To 3
Console.WriteLine("hit")
Else
Console.WriteLine("hit else")
End Select
Not having to reuse code or create a special function just for a few areas in the same Select Case/If Tree so that you can avoid reusing code, like this Javascript.
These samples are pretty contrived. There are definitely ways to simplify this scenario, but a lot of times, there aren't.
let pay = 100, perks = '';
Switch (EmpObj.type) {
Case 'Boss':
pay = pay * 10;
perks = '11 month vacation per year';
Case 'Manager':
pay = pay * 3; // This will make Boss pay * 30
Case 'Employee':
EmpObj.pay = pay;
EmpObj.perks = perks;
break;
Case 'Intern':
EmpObj.sendMessage("Go get some coffee.")
}
In VB.net, the same code would be
dim pay = 100, perks = "";
Switch (EmpObj.type) {
Case "Boss":
pay = pay * 30
perks = "11 month vacation per year"
Case "Manager":
pay = pay * 3
Case "Employee":
Case 'Intern':
pay = 0
EmpObj.sendMessage("Go get some coffee.")
End Select
EmpObj.pay = pay;
EmpObj.perks = perks;
Case, in simple situations, is easier to read and write than a comparative if-branch, but the fall-through is the best part.
GoTo Case "[label]" and Goto [Case-label] still do not work.
The label (Number2 here) must be after the Case. That was the most disappointing part.
dim Value = "1"
Select Case Value
Case "0"
' do nothing, example
Case "1"
MsgBox("one")
GoTo Number2
Case "2"
Number2:
MsgBox("two")
Case "boolean"
MsgBox("three")
' just to show it won't fall through
End Select
