Chained Behaviors

[J. Landman Gay]

For anyone who hasn't played with behaviors yet, try scripting something 
like this without them:

Create a stack. Put ten small images on the card, each with a unique 
name. These are the sprites. The stack script should already have its 
own mouseDown and mouseUp handlers that do something unrelated to the 
sprites.

Sprite handlers:

On mousedown:

Every image plays a "click" sound
Every image says its name

On mouseup:

Images 1-3 move to the top left corner
Images 4-6 change their ink
Images 7-9 play an additional sound file
Image 10 beeps

I know how I'd do it the "old" way. My existing mouseUp and mouseDown 
handlers would need to branch to accomodate what was being clicked; do 
one thing if it's a sprite, something else if it's a regular button. I'd 
assign a custom property to each type of sprite, check that to determine 
the correct behavior, and write a long switch structure with all the 
responses in it. Alternately, every sprite would need at least a 
mouseDown and mouseUp handler that at least called another handler in 
the stack.

Now try it with chained behaviors. No branching, no altering existing 
mouse handlers, no big switch statements, no custom property, no sprite 
scripts, all code in an isolated instance that does not interfere with 
any other code. It's as if every sprite is all alone on the card, 
running its own little script with nothing else in the way. And all I 
had to do is assign the behavior; the image itself has no properties or 
scripts.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com