@Charles, you are right, and that exactly is what PB does with SELECT CASE as CONST.
Let me add that in the case of an comparisson of "IF THEN ELSE" and SELECT CASE AS LONG" speed differences are so small that they can be even different on other manufacturer CPU.
Therefore I assume both as equal. While for good reasosn, the "normal" SELECT CASE is slower, because for more general use.
We see this often, that a tool that is less specific for a case, (= more general) is a bit slower.
I already posted on this case, here:SELECT CASE Comparison
But - at least PB 8.03 seems to had an limitation of a maximum of 3057 choices
for SELECT CASE AS CONST before getting the Error 402.
Now you wrote:
A structure with 20,000 CASE's executes in the same elapsed time as one with 2 CASE's
Was there a table-increase in PB 8.04
or do you talk from something we all do not know if it exists, but hope it will be available soon
Let me state that I have never needed 3000 cases, but just wondered that you give this number 20000.
I personally do not need such an big jump table, and therefore I do not wait for this, really - but I can imagine bussiness programms who would like
to get that much big.
There is one limit
I do not really understand and this Limit is not 3000 but 6
. Its the "include/Macro nesting Limit".
People making small programms and utilities upto 200, 300 kb may not even know that this exists.
But then on bigger projects, this limit may show its teeth.
When I load an Include file, this one loads an include file, that loads an includefile and that file calls a MACRO that calls a MACRO that calls a MACRO.
This limit is not 8, its not 32 or 256 its 6. I do not understand how it comes just to this number 6
But anyway, I can say, that I hope, that this limit will fall one day in the future, as this would make some things a bit easier.
Even if it would be - for example just 38 (38 = 32 + 6 :-) I'd be Ok.