Behaviors party manners

October 26, 1998
by Pat McClellan

Dear Multimedia Handyman,

I am a little frustrated. I see sites with mouse rollovers that cause graphics to appear on other parts of a page. I would love to know how to do this. Not just a simple rollover, but one that cause a change elsewhere. e.g.. on / at / WWW.macromedia.com, moving over hyperlinks causes a text description to appear lower down on the page.

Daniel

Daniel,

Don't despair. It's time to readjust how you're thinking of how multimedia works. My guess is that the only Lingo you've been using is the behaviors and simple frame scripts like "go to...", etc. The good news is that you have a whole new world of capabilities that are about to open up to you. The bad news is that you'll soon be a Lingo-junkie! You'll want to use if for everything. (Which is OK by me...)

When you first come to Director, it seems like a great program for laying out "pages" or animation sequences and creating some buttons which let you jump around from sequence to sequence. Then, you start to notice some nice little touches in other people's presentations: cursors that change on rollover, buttons and other sprites the change on rollover. So you start looking around for how to do these things and you discover behaviors! In fact, Macromedia ships a library of pre-written behaviors with the program, so getting a rollover cursor is as easy as drag 'n' drop.

Let's talk about behaviors. Most behaviors are not very popular at parties because they tend to be very self-centered. Their story is usually something like "when something happens to me, then I do something to myself." Example: when a cursor rolls over me, I change into a different graphic. Now, despite the way that I have anthropormorphized them, having a behavior be self-focused is a good thing. It "compartmentalizes" things so that the elements of your program can be self-sufficient -- not dependent on some other intelligence to monitor and direct. This is a key concept for higher level programming. Now, having said that, there are many situation in which you want to use a behavior to affect life beyond its own sprite. That's where your question comes into play.

Let's think about what happens in any script (behavior). Some event happens and, as a result, some other task is execute. Cause and effect. In the self-centered behaviors I discussed above, both cause and effect are focused on a single sprite. But they need not be. Try to separate them in your mind.

The most common events in Director include: mouseEnter, mouseLeave, mouseDown, mouseUp, keyDown, keyUp, startMovie, stopMovie, enterFrame, exitFrame. It's easy to identify what an "event" is, because you'll always see it in a script following the keyword "on". (on mouseDown, on exitFrame, etc.) Whenever these events (among others) occur, you can use scripts to control what happens in your movie. Good programming starts with isolating which events will trigger actions, and then defining what those actions will be. So let's look at your question as an example.

You want to be able to rollover sprite 1 and have that event affect a change on sprite 2. Easy. Use a behavior on sprite 1 that picks up the mouseEnter event but then changes the cast member for sprite 2. Here it is in its simplest form.


-- behavior for sprite 1
on mouseEnter me
  set the member of sprite 2 to member "changed"
end     
on mouseLeave me
  set the member of sprite 2 to member "original"
end

All that is required is that you name the cast members which will be alternating in sprite 2 according the the names in the script. It doesn't matter what names you choose -- so long as they are unique in your movie.

Now, why is that behavior so simple, when the behaviors in the Behavior Library are so long and complex? What is all that other garbage in there?

Let's say that you want to use a behavior like this over and over in your movie. Perhaps you have 10 buttons on a screen and you want a rollOver on any one of them to change a corresponding sprite. One approach is to write a behavior script like the one above for each occurance. That will work, but it's not very elegant. Wouldn't it be better if you could write only one behavior that you can re-use, assigning it the sprite and cast members each time? That, in fact, is what all that other garbage in the pre-written behaviors is. Within a behavior, you'll have a number of "handlers" or methods -- each with its own functions and responsibilities. For example, in the behavior above, we have 2 handlers: the mouseEnter handler changes the member of sprite 2, and the mouseLeave hander changes it back.

Most behaviors start off with something called a getPropertiesDescriptionList. The syntax of these handlers is enough to make you not want to learn Lingo. My recommendation is that you don't bother learning how to do it now. Just use one of the handy utilities out there to write this handler for you. I really like Behavior Writer Xtra by Roy Pardi. Whether you write it yourself or not, it's important to understand that this is the handler which brings up that handy dialog box when you drop a behavior on a sprite. In your case, you'll want the author to be able to specify which sprite, and which 2 cast members will toggle.

Each instance of your behavior will store this information in special variables called properties. That way, you don't have to hard-code which sprite and which cast members. Your code will look something like this:


-- This behavior swaps cast members in another sprite 
property pWhichSprite
property pOriginal
property pChanged
on getPropertyDescriptionList me
  set pdlist to [:]
  addprop pdlist, #pWhichSprite, [#comment:"Which ¬
    Sprite?", #format:#integer, #default:1]
  addprop pdlist, #pOriginal, [#comment:"Original ¬
    Member:", #format:#member, #default:1]
  addprop pdlist, #pChanged, [#comment:"Changed ¬
    Member:", #format:#member, #default:1]
  return pdlist
end getPropertyDescriptionList
on mouseEnter me
  set the member of sprite pWhichSprite to ¬
    member pChanged
end
on mouseLeave me
  set the member of sprite pWhichSprite to ¬
    member pOriginal
end

Again, don't let the getPropertyDescriptionList scare you. Focus on the other handlers. Notice how they differ from the first behavior we wrote above. Note that we no longer specify which sprite and which cast members. They're left a bit more abstract -- or variable to be exact. This approach is much more suited to writing code that can be re-used again and again.

Good luck with your program, and I hope we've hooked you on writing your own behaviors now!

Patrick McClellan is Director Online's co-founder. Pat is Vice President, Managing Director for Jack Morton Worldwide, a global experiential marketing company. He is responsible for the San Francisco office, which helps major technology clients to develop marketing communications programs to reach enterprise and consumer audiences.