Lesson 3 - If and Switch structures

One of the great things about SuperCard is the way there are many different routes to almost any goal. The 'if' statement can be expanded to a classic 'IF-THEN.. ELSE.. END IF' structure. Classic day-1 programming logic, and very easy to understand. (Particularly in the near plain English of the SuperTalk language.)

on mouseUp
  if the short name of me is "10" then
    set the name of me to "1"
  else
    set the name of me to the short name of me + 1
  end if
end mouseUp

The logic is simple:

If one thing is true, then
   do something
otherwise (else)
   do something else
And that's the end of this 'conditional' section. (end if)

Note the indented structure of this 'paragraph'. This is automatically created for you when you have a correct, workable script structure (with no missing items such as an 'end if'). This helps you to identify individual sections within a chunk of script as well as tell if you've written the syntax structure correctly. The formatting happens whenever you type a return (creating a new line) or a tab (which does absolutely nothing, and so is ideal for triggering the auto-format feature).

Smart alecs will have noticed a slight difference in behaviour between this script and the one from the end of the button names tutorial. That first script changes the button's name, then checks to see if it equals 10. If it does, the name is set to 1. This means the button's name is never allowed to go past 9. In the second script the 'if' statement first checks to see if the name has reached 10. If it has the name is set to 1, otherwise it is incremented by 1. This allows the name to reach 10. To make this act like the previous script we'd have to check to see if the name has reached 9 instead.

You'll notice as you rip open other people's projects that they tend to write in a kind of scripting shorthand; card becomes shortened to "cd", button becomes "btn" and so on. This is mainly to speed up script typing, but it also allows more of a script to show in the horizontal span of the Script Editor windows without scrolling sideways. It is entirely up to you how you work, but remember... some day when you help a new user out, don't scare then off with too many abbreviations too soon!

You can 'nest' a number of 'if' statements together to create a set of conditional questions using the little-known 'if..then..else if..else if..end if' structure, as follows:

on mouseUp
  if the short name of me is "red" then
    answer "Stop"
  else if the short name of me is "yellow" then
    answer "wait..."
  else if the short name of me is "green" then
    answer "go"
  end if
end mouseUp

The logic is as simple as the previous example:

If one thing is true, then
  do something
otherwise (else) if something else is true then
  do something else
otherwise (else) if something else is true then
  do something different
And that's the end of this 'conditional' section. (end if)

This can get a little unweildy, so it is worth remembering the 'Switch..Case..End' structure. This allows a large number of possible answers to a question (such as 'what is the name of that button, anyway?') to be used with a much tidier script structure, and the final script also operates ever so slightly faster in practise.

on mouseUp
 switch the short name of me
     case "red"
         answer "Stop"
         exit switch
     case "green"
         answer "Go!"
         exit switch
     case "yellow"
         answer "Wait..."
         exit switch
     case "purple"
         answer "What kind of lights are these?"
         exit switch
  end switch
end mouseUp

The way it works is actually very simple: First the thing to evaluate is defined (switch the short name of me) , then a separate 'case' section for each answer is made. The SuperTalk interpreter, the brain which reads and does the scripts, jumps to the 'case' section which matches, performs the required scripts, then drops out of the whole 'switch' structure when it encounters the 'exit switch' line of script at the end of the 'case' structure it performed.

You can also define the thing to check at the 'case' level rather than at the start of the whole 'switch' structure. This makes it even more flexible, but remember that once a match is made, a script is operated, and an 'exit switch' line is encountered, the rest of the 'switch' structure is skipped - even if there was another 'case' match about to be made.

on mouseUp
  switch
     case the short name of me is "red"
         answer "Stop"
         exit switch
     case the short name of me is "green"
         answer "Go!"
         exit switch
     case the left of me = 50
         answer "Too far over"
         exit switch
     case the hilight of card button "test" is true
         answer "This is just a drill"
         exit switch
  end switch
end mouseUp