If we like the button, we will want to use it for all four answer options. Our instinct is to copy the button for each of four answers (Figure 2.7). This instinct is fine, but immediately we encounter an important problem. Each button is an instance of the same object, and that object is programmed to display the contents of the string variable text. That means that when this movie runs, all four buttons will always sport identical labels (Figure 2.8). The buttons may delight the eye and tickle the mouse finger, but if they offer no actual choice, the players will find this quiz game pretty dull.
Figure 2.7. The Copied Button
Figure 2.8. Four Buttons ”One Variable
Consider various strategies for correcting this problem.
Namespace is an important concept in programming. It is the same as scope. Namespace refers to the phenomenon of the same name having different meanings, depending on where it is used. For instance, the identifier "Dad" could refer to billions of people, but there is only one Dad (normally) in any given family. Namespace is similar. Different objects can have properties with the same names . But because each property is accessed within the context of a different object that it resides in, each is different.
The MovieClip itself has a unique namespace. Thus a MovieClip containing four MovieClip instances can have five unique text variables : its own and one for each of the submovies. It does not matter if the four instances are of the same MovieClip symbol (prototype) or not.
So by wrapping our button in a MovieClip, we can make it addressable.
answer0.text="Snickers"; answer1.text="Mounds"; answer2.text="Runts"; answer3.text="Payday";
Though this seems similar to the previous solution, it is very different. There is only one AnswerButton button object and, in fact, only one AnswerOption MovieClip object (see Figure 2.9). Labels like answer0 and answer1 refer to instances of the AnswerOption symbol. AnswerOption contains a single instance of the AnswerButton. The base movie has four instances of AnswerButton, but they are encapsulated in the answer0, answer1, answer2, and answer3 AnswerOptions.
Figure 2.9. Buttons and MovieClip Symbols
Flash does not allow us to name button instances because button instances do not have private namespaces. We can address only the internals of named MovieClip instances. In Flash, the term target is used to refer to a such a named instance.
For historic reasons, Flash has two ways to address targets and their member components . In Flash 4, we struggled to learn a notation that imitates Unix and URL conventions. Object levels are separated by slashes . Variables are separated by colons. Parents are indicated by double dots and the root by a leading slash. In contrast, Flash 5 introduced ECMA style notation (Table 2.2). Everything is separated by dots. Roots and parents have special names. Despite its wordiness and ambiguity (see _root. carrot and _root.carrot in the table), the ECMA notation is undoubtedly superior and is used throughout this book. The ambiguity demonstrated in the table is overcome by the restriction that a MovieClip object and a data variable cannot use the same name in the same namespace.
Table 2.2. Different Syntax for Reference
Now that we have an AnswerOption that is more capable than the AnswerButton, we need to retrofit our Question display. Returning to the Start frame, we can right-click on each of the buttons, one at a time, to automatically select the correct keyframe and bring up the Instance panel.
The leftmost icon is Swap Symbol. Use it to change each of the AnswerButton references to AnswerOptions.
Click the desired choice, and then set the behavior and name it.
At last we can act like programmers, not clerks. By addressing each instance of the AnswerOption object by name, we can inject data into it (see Figure 2.10).
Figure 2.10. Four Buttons ”Four Variables
answer0.text="William the Conqueror"; answer1.text="William the Bastard"; answer2.text="William the Bald"; answer3.text="William the Duke of Normandy"; stop ();
The text, of course, will be visible only as the movie plays.
It is a little disturbing to write to a variable ( text ) that not only does not yet exist but is in an other object's namespace ( answer0.text ). Certainly it violates the principles of real object-oriented programming to directly write to a variable that resides in another object. Normally a method of the class would be especially designated to set the text (so that the fundamental design of the object could change, but no code that uses the object would have to). It is shocking simply to write to one that does not even exist. (The AnswerButton will read the text variable but does not declare, define, or assign it.) The primary reason is to prevent accidental overwrites and other miscommunication between programmers, or between us and us when we come back to the code in three weeks.
It is also true that ActionScript variables are visible globally. Some other object-oriented languages allow us to restrict access to our object's variables. Data hiding ”the protection of an object's variables by the privacy of its namespace ”offers a higher degree of security, something like the protection of an unlisted phone number. Although the access syntax and the usage of MovieClip variables are similar to those of the instance variables of an object, this is not pure object-oriented programming. This form of data encapsulation provides for instantiation and packaging of variables for each MovieClip but not data hiding.