Important point should be mentioned in the user manual!
If you look over this code:
OPENCONSOLE
SELECT Pilot()
CASE 1
CASE 2
CASE 3
ENDSELECT
DO:UNTIL INKEY$<>""
END
SUB Pilot(),Uint
PRINT "HELLO"
RETURN 3
ENDSUB
You would expect that SUB Pilot get called only once.
But actually it gets called 3 times!
So take a note dude!
;)
Csaba
Interesting, but this works fine:
OPENCONSOLE
def res as Uint
res=Pilot()
SELECT(res)
CASE 1
PRINT "1"
CASE 2
PRINT "2"
CASE 3
PRINT "3"
DEFAULT
PRINT "DEFAULT"
ENDSELECT
DO:UNTIL INKEY$<>""
END
SUB Pilot(),Uint
PRINT "HELLO"
RETURN 3
ENDSUB
Yes it dose.
Look’s like the â€Ã...“inline commandâ€Ã, temporary return parameter doesn’t get pushed at the stack or something like that.
This behaviour is by design. Unlike a table based select/case the one used by Emergence and Aurora is dynamic. It allows for more flexability in the CASE statements themselves. One of the limitations of table based switch/select statements is the case values have to be constant at compile time.
In Emergence you can consturct a truth based select whose case values won't be known until runtime:
select 1
case a < b
print "a < b"
case a > b
print "a > b"
case a = b
print a = b
endselect
In C that is just not possible ;)
Cool!
Hi Ficko,
I think you might be bending the language a bit there .. :)
The item after 'Select' needs to be a variable, or 'True' to test the various Case conditions.
So you could have:
OPENCONSOLE
SELECT true
CASE Pilot()=1
print "1"
CASE Pilot()=2
print "2"
CASE Pilot()=3
print "3"
ENDSELECT
DO:UNTIL INKEY$<>""
END
SUB Pilot(),Uint
PRINT "HELLO"
RETURN 3
ENDSUB
or:
OPENCONSOLE
value = Pilot()
SELECT value
CASE 1
print "1"
CASE 2
print "2"
CASE 3
print "3"
ENDSELECT
DO:UNTIL INKEY$<>""
END
SUB Pilot(),Uint
PRINT "HELLO"
RETURN 3
ENDSUB
The latter is I think the best way, 'cos it only calls the subroutine once .. :)
The way you coded it, the Select statement will see Pilot() as the 'value' to check the cases against.
So 'case 1' will fail, as will 'case 2'. 'Case 3' finally succeeds - but you're right - it is inefficient stated in that form.
I'm surprised EBasic handled that format as well as it did. I would have expected it to complain ..
all the best, :)
Graham