@Obese
What is '.' evaluating to in the select portion? It may be undefined in this case or point to a NULL pointer. If it evaluates to a float, then it may not be making a reliable comparison to integer values being returned in the case conditional tests.
The numeric values in DBC are actually strings that are pointers to values. By default, the numbers point to values of themselves but you could easily change their value:
So you may not be getting the value you want with Select .
Also, logical conditional tests might not actually work in a case statement. They may only be triggered by the presence of a number or variable, like the 1 or the 0. If 1 is present the condition is true, if the zero is present the condition is false. So if your test after the case statement is (keystate(32)=0), it may only be picking up the 0 and returning a false. For a test, try setting the values to 5 or 6 or -29 and see what happens. I'm not at a computer with DBC right now so I can't test any of this.
Quote: "I could be wrong, but doesn't SELECT exit once it hits a valid CASE statement?"
No it doesn't. It evaluates all case conditions. That's why in long select case blocks, for speed I use a jump from the case block to the endselect:
a=1
select a
case 1
rem do stuf
goto _endthis
endcase
rem many more case blocks each with an _endthis jump
_endthis:
endselect
Enjoy your day.