SuperCard icon ᄅ Solutions Etcetera - used with permission
SuperCard icon ᄅ Solutions Etcetera - used with permission Reference
SuperCard icon ᄅ Solutions Etcetera - used with permission
SuperCard icon ᄅ Solutions Etcetera - used with permission buttons & names more on names IF and SWITCH read & write data
SuperCard icon ᄅ Solutions Etcetera - used with permission

SuperCard: the easiest, most flexible way to make stuff for your Mac

Getting to grips with variables

Variables. Hmm. I generally try to explain them as a form of virtual post-it note. You can use them to store information in an ad-hoc, non-permanent kind of way, and use them to hold some info that might change at some point. Variables exist as named items. You can just name them as you need them for short-term use ('local', or temporary variables) or define them as global variables for a longer-term existence.

Short-term means they exist only within the lifespan of a run of the script handler that uses them. So the script:

on mouseUp
  put 10 into myNumber
end mouseUp

is pretty useless, because the 'myNumber' variable simply ceases to exist as soon as the mouseUp handler ends. But if you use:

on mouseUp
  global myNumber
  put 10 into myNumber
end mouseUp

...then the myNumber variable will live on, available to any other script that happens to use the "global myNumber" line to access - or change - that particular global variable.

Many experienced users will prefix their variable names with either 'g' (for global variables) or 't', or sometimes some other character or set of characters. This serves to identify what kind of variable it is, and it also helps ensure that the name you use won't happen to be the same as some official SuperTalk word. For example, "name" is an existing SuperTalk word and not available for use as a variable (or handler) name. But gName ...or tName, or theName, myName, thatDamnName... anything which turns it into a non-word works fine, although following the general conventions is a good idea.

If you find the 't' prefix ugly and hard to read, you’re not alone. It is a good concept, but using ‘the’ rather than ‘t’ can be a little easier to bear. However, most scripters do use the single-letter approach to variable name prefixes. (The important thing is to be both clear and consistent with this, so when you or anyone else has to look through your scripts months afterthey've been written they are relatively easy to understand.)

A hypothetical example:
When someone runs your project, part of the startup procedure puts the time of startup into a global variable.

on startup
  global gStartTime
  put the time into gStartTime
end startup

This can now be referred to whenever necessary, as long as the handler in question has used the "global gStartTime" line.

on mouseUp
  global gStartTime
  answer "You started at" && gStartTime & "."
end mouseUp

The "You started at" text is concatenated, or merged with, the next item with the '&&' keyword, which includes a space between the two items it joins. The next item is the variable name, and SuperTalk uses its contents when retrieving it. The last item, the period (or full stop for non-US readers) is added on with the '&' keyword, which DOESN'T build in a space. (The period is completely unimportant, but it makes the sentence read just that little bit better.)

Temporary variables are often used in things like repeat loops. For instance:

on mouseUp
  repeat with x = 1 to 10
    go to card x
    paste objects
  end repeat
end mouseUp

...will automatically paste something on cards one through ten with a minimum of effort. Of course, you'l have to have copied some object (such as a graphic, button or field) prior to running this script for it to work.

As this last script should demonstrate, scripts can be very useful for building and modifying stuff during production, not just for creating the scripted interaction in the end product. Remember this well.

 

Reference more on names buttons & names IF and SWITCH more on names read & write data IF and SWITCH read & write data