| First of all, let's talk a little about event-driven programming in general. Unlike traditional programming, where the code follows its own control flow (remember goto and gosub?), the control flow of an event-driven program relies largely on external events. In a GUI environment such as Director's, an event can either be generated by Director, or it can be generated by the user. The event might be the user clicking a mouse button or pressing a key on the keyboard, or it might be Director leaving or entering a frame. Either way, when an event is generated Director sends a message about the event. The message travels from its origin, checking at various locations to see if it can be handled. If a handler exists for the message, the message stops and the handler runs. If no handler exists, the message eventually falls through the bottom of the hierarchy and disappears. Examine the following image, which shows an example of a user generating events with the mouse. Here, a sprite on the Stage is clicked; this generates two events: a mouseDown when the button is depressed, and then a mouseUp when the button is released. 
The messages travel first to the behavior script attached to the sprite itself, where a mouseUp handler is encountered. The mouseUp message stops, and the handler's code is executed. Meanwhile, the other mouseDown message continues on, stopping next at the script attached to the sprite's cast member. Because no mouseUp handler exists, the message continues on to the behavior attached to the current frame, and then finally to the movie script level. Because no mouseDown handler is ever encountered, the message disappears. There is an exception to the rule of messages stopping when they are handled, and that is with behaviors attached to sprites. Because multiple behaviors can be attached to a single sprite, any messages sent to the sprite are sent to each behavior in the order they are attached to the sprite. A quick example will make this clear. 1. | For testing purposes, start a new movie by selecting File > New > Movie from the top menu, and then use the Tool palette to create a rectangle on the Stage.
For testing, any old sprite will do, and the shapes in the Tool palette are readily available.
| 2. | Right-click the sprite, select Script from the context menu, then add line 2 to the default mouseUp handler, as shown:
1 on mouseUp me 2 trace("mouseUp1") 3 end
As you know, this will simply put mouseUp1 into the Message window when the sprite is clicked. You need to add another behavior to the same sprite to see how the message gets passed.
At this point, I'd like to mention a couple of reasons for using the Score's sprite toolbar for adding multiple behaviors. One, it is quicker than using the Behavior inspector; and two, using it places a default script into the new behavior instead of creating a blank behavior, as the Behavior inspector does. It's also nice in that it shows a preview of the first behavior attached to a sprite.
| 3. | Right-click in the Score's Frame bar and select Sprite Toolbar from the contextual menu. Make sure the sprite you just created is still selected.
 With the sprite toolbar showing, notice that in the Behaviors drop-down menu the first bit of the behavior attached to the sprite is showing. Now, lets add the second behavior.
| 4. | Click the Behaviors drop-down menu and select New Behavior from the list. Again add line 2 to the default mouseUp to create the following:
1 on mouseUp me 2 trace("mouseUp2") 3 end
You now have two different mouseUp behaviors attached to the same sprite. Notice too, that the behaviors drop-down menu in the sprite toolbar now lists <Multiple>, telling you the selected sprite has more than one behavior attached.
| 5. | Open the Message window, play the movie, and click on the sprite.
When you click the sprite on the Stage, you see the text in the Message window:
-- "mouseUp1" -- "mouseUp2"
As you can see, the mouseUp message generated by clicking the sprite was sent to both behaviors attached to the sprite. Notice, too, that the message was sent in the order you attached the behaviors.
| 6. | Stop the movie and make sure the sprite is selected. Then open the Behavior inspector by selecting Window > Behavior Inspector from the top menu, or by selecting the Behavior tab in the Property inspector. If you have the sprite toolbar in the Score open, you could also press the Behavior inspector button there.
The Behavior inspector lists all the behaviors attached to a sprite and allows you to change their order, open them for editing, add existing ones, or remove attached ones.
| 7. | Select the second behavior in the list (member 3) and press the Shuffle Up button as shown.
With the behavior order changed, the mouseUp handler in script member 3 will now be called before the script in member 2.
| 8. | Play the movie and observe the results when you click the sprite.
This time when the sprite is clicked you can see how the order has changed:
-- "mouseUp2" -- "mouseUp1"
While being able to attach multiple behaviors to the same sprites is a great feature, under- standing how messages are passed to the behaviors is required if you're to truly grasp the event->message->handler structure.
|
|
