Variables Are Just Containers

How programs store information is actually pretty simple­they store it internally (in variables) and externally (in files). That’s it. Those are really your only two options here.

Consider your word processor, for instance. When you select some text in it to copy and paste someplace else, that text is copied to a variable­a storage container the word processor has created in your computer’s memory­and when you paste the text, it’s taken out of that storage container and inserted in a new place in your word processing document.

Similarly, when you save your word processor file to disk, everything you’ve done is written to your computer’s drive as magnetic information (something like how audio or video cassettes store sound and images).

We’ll tackle variables here, because I believe you’ve worked with your computer enough by now to understand the idea of opening and closing files in a given program.

Run your copy of Director and, if its Message window is not already open, choose Window | Message. Into that window, type the following:
 

myVariable = "Hello"


followed by the return key. You’ve just done it­you’ve created a variable, and stuffed something into it.

A variable, in all the world of computing, is a beast that never really changes. It is a container that is used to store something, and that can be read (or accessed, or looked into) at pretty much any time thereafter, allowing you (or your program) to actually see its contents.

Immediately after the line you just typed into Director’s message window, type the following:
 

put myVariable


followed, again, by return. What happened? Director did this:
 

-- "Hello"


The put command is used to tell Director to take the contents of a variable and put those contents into the Message window, where you can see them. In this little example, it simply acts as proof that Director did, in fact, correctly store the "Hello" you put into the variable myVariable, and that it’s still there in memory, waiting for you to access it.

Now quit your copy of Director entirely, and run it again. Reopen the Message window, and into it type the following. Before you press return, though, I want you to try to guess what will happen.
 

put myVariable


What happened this time? Director should have done this:
 

-- <Void>


This is Director’s way of telling you that myVariable is empty. More than that, it’s telling you that myVariable never, in fact, had anything in it to start with.

Wait a minute, you’re surely thinking­I just gave it a value a minute ago; I put the word "Hello" into it.

Aha, but in the meantime you also quit Director and reopened it, causing it to completely forget everything you did before.

This is referred to as volatility. It means that any variables you create, and anything you put into them, will all be forgotten when the program quits. The storage space the program sets aside in your computer’s memory is volatile. Anything in there gets completely wiped every time a program exits, or every time your computer restarts. If you think you have bad short-term memory, well, your computer has none at all.

This is, of course, why it’s important for programs to be able to save things to files on disk periodically. When a program saves a file, it is writing information to a hard drive that has been specifically formatted­prepared­so the program can reconstruct the work you have done next time you open it. Without this ability to store information, computers would really be no more useful than pocket calculators, most of which also forget everything you were doing as soon as you turn the power off.

Thus work you do in Director itself, as you go along, is stored in your computer’s memory as a (rather complicated) set of variables. When you save your Director movie to disk, all that information gets written to your drive in a formatted way that permits Director to restore­come back to­the place you left off when you quit the program.

Tip: Variables, in Lingo, can be one word only. You can’t have a variable named my variable; Director won’t understand. You can, however, have one named my_variable, but not my-variable (because Director will read that as ‘the value of my minus the value of variable’). Variables also cannot begin with an initial number; you can’t have a 2Variable. However, you can have a Variable2. In addition to the generic ability to create variables, put things into them, and find out what they contain, there are the issues of scope and persistence. Scope generally refers to how "available" a given variable is, and persistence generally refers to how long it lasts in a program.

Let’s do a quick demonstration here. Start with a new Director file and use the Tool Palette to create a button sprite on your Stage, giving it any text you want.

Next, open the script window for the button Cast member by selecting the button in the Cast, then clicking the little document with an arrow in it.

You will see the following:

on mouseUp

end

with a cursor blinking between the two lines. Into that space, type the following:

myVar = myVar + 1
put "My variable is:" && myVar

If you’ve done it properly, it’ll look like this:

on mouseUp
myVar = myVar + 1
put "My variable is:" && myVar
end

Note, by the way, that Director automatically indented the lines for you. Why this is interesting will be discussed a little later in this module.

Here you have created a simple script­a very brief program­which tells Director to do something. Line by line, this is what the preceding code means:

on mouseUp

This tells Director that it is supposed to do whatever follows this line whenever the button containing this script has been clicked with the mouse. Every time the user clicks this button, its on mouseUp script is activated.

myVar = myVar + 1

This tells Director to take the current value of the variable myVar and add 1 to it. This might seem a little confusing because myVar appears on both sides of the equal sign, and that’s just the way it works with most programming languages. Everything on the right side of the equal sign generally gets stuffed into whatever is on the left side of the equal sign. We’ll explore this a bit more later in this module.

The equal and addition signs are operators, or symbols that tell the computer to behave in a certain fashion. Typically mathematical operators are the kinds you’re likely to see and use most. The other common ones are (subtraction), / (division), and * (multiplication).

put "My variable is:" && myVar

You’ve seen the put command already. What we’re doing is telling Director to place the text "My variable is:" into the Message window, followed by the value of myVar. We know we’re putting the value of myVar­what the variable actually contains­into the Message window instead of simply the word "myVar" because we have not placed quotation marks around myVar.

The double ampersand is deliberate, by the way, not a typo. This tells Director to put the value of myVar after the phrase "My variable is:" and to put a space between the two when it dumps the entire line into its Message window. We add the space to make the output a little more readable.

end

This tells Director that this is the end of this script­there’s nothing else for it to do, so that’s the end of the mouseUp script for this button.

Now go ahead and click the Play button. Each time you click your newly scripted button, you might expect to see the following output in the Message window:

-- "My variable is: 1"
-- "My variable is: 2"
-- "My variable is: 3"
-- "My variable is: 4"
-- "My variable is: 5"

That is, you might expect the value of myVar to increase by 1 each time you click your button, because that’s presumably exactly what you wrote the program to do.

Of course that’s not what you see at all. What you discover, in fact, is that no matter how many times you click your button, the value of myVar never, ever exceeds 1.

This is because Director actually forgets the myVar variable just as soon as it’s done running the script. This means that the variable’s scope­how available it is to the rest of the program­is limited only to this script; its scope is said to be local. Furthermore, its persistence­how long the contents of the variable actually stay in memory­is limited to a single run of the script. The result, of course, is that its persistence prevents it being remembered even from mouse click to mouse click.

Every time the script runs, then (that is, each time you click your button), it starts with myVar being <Void>, or completely brand new and containing no value whatsoever. By adding 1 to its value, you have set the contents of myVar equal to 1. As soon as the script is finished, Director completely forgets everything it just did, forgetting the variable, its contents, what you did with it­everything.

You can actually prove this scope and persistence limitation to yourself by changing your button script a little:

on mouseUp
myVar = myVar + 1
put "My variable is:" && myVar
myVar = myVar + 1
put "My variable is:" && myVar
end

This will force Director to add 1 to the variable twice each time you click the button, and then put its description into the Message window after doing so.

What do you think will happen when you click Play now, and then click your button a few times?

Try it and see if the results are what you expected.

There is a way to increase the persistence and scope of your variable, thus giving it a life beyond the script that contains it, and that is to use the special Director keyword GLOBAL. If you first declare your variable as global­meaning you specifically enter an extra line of Lingo at the beginning of your button’s script­the scope and persistence of the variable will no longer be limited to just that script. It will become something you can "see" and use anywhere else in your Director movie.

Here’s the modified script:

on mouseUp
GLOBAL myVar
myVar = myVar + 1
put "My variable is:" && myVar
end

Note the extra line, where we use the keyword GLOBAL before myVar.

Now try running your program and clicking your button. See what’s happened there?