Announcement

Collapse
No announcement yet.

Cutting down on SELECT CASE options?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Frank Ferrell
    replied
    Greetings --

    Originally, I had posted a 2nd example of SELECT CASE here. Since then, the code has been revised in a manner that doesn't require SELECT CASE.

    Thanx-A-Lot, Frank Ferrell

    [This message has been edited by Frank Ferrell (edited June 18, 2003).]

    Leave a comment:


  • Frank Ferrell
    replied
    Greetings --

    This was just a thought --

    Code:
    Ziz$=Str$(OptionNo)
    Ziz$=Trim$(Ziz$)
    IF OptionNo<100 THEN Ziz$="0"+Ziz$:' These 2 IF lines are optional
    IF OptionNo<10 THEN Ziz$="00"+Ziz$:' Just depends on user needs
    Select case OptionNo
        case 1 to 100
             Filename$="C:\game\part"+Ziz$+".exe"
    End Select
    Thanx-A-Lot and Enjoy, Frank -- My PB


    [This message has been edited by Frank Ferrell (edited June 21, 2003).]

    Leave a comment:


  • Tom Hanlin
    replied
    Not needed, Robert. CASE checking is only done until a match is found. If
    stepping the code through the debugger suggests otherwise, it's just a
    side-effect of how the debugger works.


    ------------------
    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:


  • Robert E. Carneal
    replied
    Originally posted by Jerry Fielden:
    If you put EXIT SELECT in each CASE, will it still do that?

    I had to go back and check. BRAVO! No it will not do that after putting EXIT SELECT in each CASE.

    I should have known since I use EXIT IF and EXIT FOR. I guess
    I forgot EXIT SELECT was available.

    Thank you.

    Robert

    ------------------

    Leave a comment:


  • Jerry Fielden
    replied
    If you put EXIT SELECT in each CASE, will it still do that?

    ------------------


    [This message has been edited by Jerry Fielden (edited May 21, 2003).]

    Leave a comment:


  • Tom Hanlin
    replied
    I can still use DOS Powerbasic in a DOS screen/box in XP, correct?
    Sure.

    ------------------
    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:


  • Robert E. Carneal
    replied
    Originally posted by Lance Edmonds:
    if Robert has code that exhibits that symptom, then I would realy suspect some other problem exists in the code (such as memory corruption, etc).

    Adding $ERROR ALL ON can help locate the most common cause:- accessing an array past its bounds.

    I think I am getting somewhere now. I have been using the
    debugger and going step-by-step, line-by-line, etc., and it is
    this time I notice it checking through all CASE statements,
    even beyond the one that fit the criteria. I want it to stop
    checking the CASE after finding the correct one, hence my
    desire for something that behaved like embedded SELECT CASE
    originally.

    I currently do not have $ERROR ALL ON. I will try that
    and report what result I do have. I do have 384M of memory, and
    just have not felt like adding more memory due to a new computer
    arriving in a few weeks.

    This is off this particular topic, but the speaking of the new
    computer- it will have Windows XP Pro. I can still use DOS
    Powerbasic in a DOS screen/box in XP, correct?

    Thank you.

    Robert

    ------------------

    Leave a comment:


  • Lance Edmonds
    replied
    PowerBASIC definitely does NOT work like that, so if Robert has code that exhibits that symptom, then I would realy suspect some other problem exists in the code (such as memory corruption, etc).

    Adding $ERROR ALL ON can help locate the most common cause:- accessing an array past its bounds.

    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Michael Mattias
    replied
    2. It finds case number two, sets the value of Filename$ to "C:\game\part2.exe"
    just fine. But it goes on to check case 3, case 4, etc.
    You are suggesting the compiler generates code to test every case, doing nothing if the test has already been met?

    If that's true ... that's a bad bug in the compiler which surely would hav been detected in the ten-plus years PB/DOS compilers have been available.

    I'd suspect some quirk in the stepping debugger; but I think you need to bundle up your source code and send it to pb support along with an explanation.


    MCM



    [This message has been edited by Michael Mattias (edited May 21, 2003).]

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Read the manual:

    "As soon as an evaluation is TRUE (non-zero), the statements following that CASE clause are executed, up to the next CASE clause.
    Execution then passes to the statement following the END SELECT statement. If none of the evaluations is TRUE, the statements following the optional CASE ELSE clause are executed."

    But until it founds the item, it must check every case instruction to see if it meets the requirements expressed in SELECT CASE.



    ------------------

    Leave a comment:


  • Robert E. Carneal
    replied
    Originally posted by Michael Mattias:
    Call me old-fashioned, but if it didn't do this, I think I might go so far as to suggest it's a bug.

    MCM

    Michael, well, maybe it IS the way it is supposed to work. My
    training of CASE statements is once the CASE is carried out,
    it gets out of the Select statement. I.e., if
    Code:
    Select case OptionNo
        case 1:Filename$="C:\game\part1.exe"
        case 2:Filename$="C:\game\part2.exe"
        case 3:Filename$="C:\game\part3.exe"
        case 4:Filename$="C:\game\part4.exe"
        case 5:Filename$="C:\game\part5.exe"
    '     etc. etc.
    END SELECT
    What I am saying is supposed OptionNo is = 2. It finds case
    number two, sets the value of Filename$ to "C:\game\part2.exe"
    just fine. But it goes on to check case 3, case 4, etc. I
    thought once it found a case, it executed the statements for
    that case, and goes to END SELECT.


    Jim- You are right. This is really for another program, but I
    a have program of asking questions clearly. Let me try anyway.
    Is the above example better?

    [This message has been edited by Robert Carneal (edited May 20, 2003).]

    Leave a comment:


  • Michael Mattias
    replied
    SELECT CASE is checking every possibility, rather than avoiding some of them.
    Call me old-fashioned, but if it didn't do this, I think I might go so far as to suggest it's a bug.

    MCM

    Leave a comment:


  • Jim Cody
    replied
    Your example implies an attempt to emulate the classic "Simon Says" program that has been around since the first Apple Computers were introduced. Unless there is more to it than you have revealed, I don't see how equating text strings to a flat list of integers is going to make Simon very wise or engaging.

    I have no links to offer, but I know that Simon Says source in BASIC used to be listed in a lot of BBS sites.

    ------------------
    Jim C.

    Leave a comment:


  • Mike Luther
    replied


    That's also

    Put another way: (paraphrasing) Occam's Razor: All other qualities
    being equal, the simplest choice tends to be the best and most
    reliable.
    an argument for portability if you happen to need it.



    ------------------
    Mike Luther
    [email protected]

    Leave a comment:


  • Mel Bishop
    replied
    Originally posted by Michael Mattias:
    ...always put the more likely first...
    Put another way: (paraphrasing) Occam's Razor: All other qualities
    being equal, the simplest choice tends to be the best and most
    reliable.


    ------------------

    Leave a comment:


  • Michael Mattias
    replied
    With many choices, always put the more likely first in the test list.

    MCM

    Leave a comment:


  • Guest's Avatar
    Guest replied
    ON n GOTO is the fastest way, but the range of n is only 0-255. Arrays are also fast, but with so many elemenets you will need to use virtual arrays. I think a good choice will be put the strings in a random file. The access is fast and you don't waste precious DOS memory.


    ------------------

    Leave a comment:


  • George Bleck
    replied
    Whoops...forgot which forum section this is

    I stand corrected, Eric is on the money.

    ------------------
    Every day I try to learn one thing new,
    but new things to learn are increasing exponentially.
    At this rate I’m becoming an idiot faster and faster !!!
    ------------------
    George W. Bleck
    Lead Computer Systems Engineer
    KeySpan Corporation
    My Email

    [This message has been edited by George Bleck (edited May 13, 2003).]

    Leave a comment:


  • Eric Pearson
    replied
    > You could try using SELECT CASE AS LONG

    Nope, not in PB/DOS you can't.

    Robert, by far the fastest way to do a complex selection with PB/DOS is ON GOTO.

    -- Eric


    ------------------
    Perfect Sync Development Tools
    Perfect Sync Web Site
    Contact Us: mailto:[email protected][email protected]</A>



    [This message has been edited by Eric Pearson (edited May 13, 2003).]

    Leave a comment:


  • George Bleck
    replied
    You could try using SELECT CASE AS LONG to get a speed up using
    a jump table.

    There are a number of other ways to do it. Probably the most
    straightfoward according to what you asked is embedded SELECT CASES.
    Code:
    SELECT CASE SomeValue
      CASE 0 to 99
        SELECT CASE SomeValue
          CASE 0 TO 9
            SELECT CASE SomeValue
              CASE 1:PRINT "Say This"
              CASE 2:PRINT "Say That"
          CASE 11 TO 19
            SELECT CASE SomeValue
              CASE 11:PRINT "Say This"
              CASE 12:PRINT "Say That"
            END SELECT
        END SELECT
    END SELECT
    You could also use ON x GOTO

    Though the best way would be to store all your strings in an array
    and reference them with their subscript. No SELECT CASE required!

    PRINT SayArray(127)


    ------------------
    Every day I try to learn one thing new,
    but new things to learn are increasing exponentially.
    At this rate I’m becoming an idiot faster and faster !!!
    ------------------
    George W. Bleck
    Lead Computer Systems Engineer
    KeySpan Corporation
    My Email

    [This message has been edited by George Bleck (edited May 13, 2003).]

    Leave a comment:

Working...
X