Writing Lingo Scripts

This chapter is from the book

Special Edition Using Macromedia Director MX

Learn More Buy

This chapter is from the book

This chapter is from the book 

Special Edition Using Macromedia Director MX

Learn More Buy

Understanding Messages and Behaviors

When you run a Director movie, certain things are put into motion. Sprites are displayed, messages are sent to scripts, and the movie moves forward, frame-by-frame. Or perhaps not, if you have placed Lingo code to stop it.

Understanding what happens when a movie runs is the key to writing Lingo code and controlling the movie.

Movie Event Messages

As the movie runs, events occur. For instance, when a new sprite is encountered for the first time in the Score, the beginSprite event occurs. This triggers an on beginSprite message that is sent to the appropriate part of the movie, in this case the sprite's script.

One way to divide these messages is into two groups: messages sent to global movie scripts, and messages sent to frame and sprite scripts. The first group includes prepareMovie and startMovie, which can be used to trigger handlers to perform actions when the movie starts. The stopMovie message, likewise, can be used to trigger commands that happen when a movie is done.

Frame and sprite scripts have another set of messages. The beginSprite message is sent when the frame script or sprite span is first encountered during movie playback. Then the prepareFrame, enterFrame, and exitFrame messages are sent while each frame plays out. Finally, an endSprite message is sent when the sprite span ends.

Table 3.4 shows a run-down, in order, of the messages sent by the movie as it runs.

Table 3.4 Movie Event Messages

In a typical sequence, the first few messages are triggered when the movie starts. Then, after the exitFrame messages, the sequence loops back to the prepareFrame messages. The endSprite messages happen whenever a sprite ends, but the stopMovie message only when the movie is done or is stopped.

The exception to this is the idle message. This is repeated several times depending on how much time the movie has between enterFrame and exitFrame messages. If time is tight, then only one idle message will be sent. But if the movie must delay itself between enterFrame and exitFrame so that it can stick to a slower frame rate, then the idle message may happen multiple times.

So now that we know all of the messages sent when a movie plays, the next step is learning how to use them. To do this, you need to write handlers.

An event handler always has the same name as the message it is meant to handle. For instance, if you want to write a movie script that should execute when the movie starts, you would write an on startMovie handler and place it in a movie script. Here is an example:

on startMovie
 gScreensVisited = 0
end

If you want to write a frame or sprite handler that runs when a sprite span begins, you would write an on beginSprite handler and place it in a script attached to that frame or sprite.

on beginSprte
 sound(1).play(member("intro sound"))
end

It is important to remember to use handlers in appropriate places. For instance, an on startMovie handler belongs in a movie script and will only work properly there. An on beginSprite handler belongs in a frame or sprite script, and only belongs there.

User Event Messages

There is a whole other set of messages that don't happen automatically. Instead, they happen in reaction to user events.

The most common example is when the user clicks on a sprite. A mouse click can be dissected into two parts: when the user presses down on the mouse button, and when they release it. Both of these events have a corresponding message: mouseDown and mouseUp.

In the case of user event messages, the message is passed from one part of the movie to another until it finds a handler to deal with it. For instance, if the user clicks on a sprite and creates a mouseUp message, the message is sent first to the sprite's script. In there is an on mouseUp handler attached to that sprite, it will trigger that handler. The message does not continue on from that point until special Lingo is used to pass it along to the next level.

However, if the sprite has no behavior with an on mouseUp handler in it, the message continues to look for a receiving handler.

The next place it looks is in the cast member. It checks to see whether an on mouseUp handler has been placed in the cast script. If not, it checks the behavior in the Frame Script channel. Finally, if that fails, it looks for an on mouseUp in a movie script member.

If it still cannot find a handler to receive the message, the message is simply not used.

Messages look for handlers in

• A behavior attached to the sprite acted upon. If there is more than one behavior, it looks at them in the order that they appear in the Behavior Inspector.

• The cast script.

• A behavior in the Frame Script channel.

• Any movie script cast member.

Table 3.5 shows all of the user event messages.

Table 3.5 User Event Messages

The keyDown and keyUp messages will only ever happen if the sprite has some sort of link to the keyboard. An example would be a text member set to be editable. The user can click in that text member and type. Each key press generates a keyDown and keyUp message that can be intercepted with an on keyDown or on keyUp handler.

Connecting Messages to Sprites

When a message, such as mouseUp, reaches a sprite's script, it carries with it one piece of information: a reference to the sprite itself. This seems redundant. After all, why does a script need a reference to the very sprite it is attached to? Doesn't it already know which sprite it is attached to?

But this allows us to capture that reference and give it a name. By convention, this name is always me. For instance, look at this script:

on mouseUp me
 go to frame 7
end

The me is the first parameter of the handler. The event calls the handler and places a reference to the sprite inside of me. We can then use me to get information about the sprite. For instance:

on mouseUp me
 put me.spriteNum
end

When this button is clicked, the spriteNum property of me is place in the Message panel. This property, which is the one most commonly used for sprites, tells us the sprite number of the sprite that the script is attached to. If the previous script is attached to sprite 3, the result will be a "3" in the Message panel. Move the same sprite down one channel, and you will get a "4" when the sprite is clicked.

If you are not accessing any properties of the sprite, you don't need to use the me parameter. But since it is so common to need properties such as spriteNum, the me parameter is usually placed after the handler name in every case. This is only true for sprite and frame scripts, as movie script handlers do not get a me parameter passed to them.

Creating Your Own Properties

The spriteNum property is built-in to the script's me object. However, you can also create your own custom properties that will be available to all of the handlers in the script.

Properties are special variables that maintain their values during the life of a sprite. To declare a property, we need to use the property declaration in the script. By convention, it is placed before the first handler.

property pJumpFrame

Once declared, the variable pJumpFrame can be used in any handlers in that script. Any value you set it to will persist for other handlers, or the next time that same handler is called.

For instance, this script will set the property in the on beginSprite handler that runs when the sprite first appears on the Stage. It then uses that property later in the on mouseUp handler.

property pJumpFrame

on beginSprite me
 pJumpFrame = 7
end

on mouseUp me
 go to frame pJumpFrame
end

While this script doesn't have any advantage over the previous version, it does demonstrate the use of a persistent property. Now, we'll see how properties can be used to make scripts more useful.

Creating Simple Behaviors

In the previous script, when the sprite begins, it sets pJumpFrame to 7. It then uses this value in a go command when the user clicks.

What would be great is if you could apply this same script to several buttons, but have each button have a different value for pJumpFrame.

So one button would use a pJumpFrame of 7, the second would use a value of 9, the third a value of 13. There would only be one script, but it would be used three times, each with a different value for pJumpFrame.

The way to do this is with an on getPropertyDescriptionList handler. This handler will be used to customize the value of a property on a per-use basis. So each time you apply the script to a sprite, you get to tell the script what value it should use for pJumpFrame.

Here is what a script would look like that allows you to customize pJumpFrame for each application of the script.

property pJumpFrame

on getPropertyDescriptionList me
 return [#pJumpFrame: [#comment: "Jump To:", format: #integer, #default: 1]]
end

on mouseUp me
 go to frame pJumpFrame
end

The value returned by the on getPropertyDescriptionList function is a property list that contains one or more other property lists. The property name for the first (and only, in this case) item of the list is the name of the property, turned into a symbol by adding a # in front of it.

The list that is its property value contains three items. The first is the #comment property. This is the string that the Parameters dialog box will show for this parameter. The second item, #format, tells the Parameters dialog box which types of values to accept for this parameter. The last item is a default value for this parameter.

When you drag this script to a sprite, a Parameters dialog box will automatically appear. It will look like Figure 3.9.

Figure 3.9 The Parameters dialog box appears when you drop a behavior on a sprite and that behavior needs custom parameters set.

This behavior can now be attached to many sprites, but with a different target frame each time. This reusability is one of the powerful features of behaviors. You can have a movie filled with navigation buttons, but you need only this one behavior.

In addition to getting the Parameters dialog when you drag and drop the script on to a sprite, you can also bring it up at any time by selecting the sprite, using the Behaviors tab of the Property Inspector, and clicking the Parameters button at the top of that tab. The Parameters button's icon looks like two gear wheels. This way you can change the value of the parameters at any time.

When a script contains customizable parameters, it is usually referred to as a behavior. Some programmers refer to all sprite and frame scripts as behaviors, while others reserve that name only for customizable ones with on getPropertyDescriptionList handlers.