One ancestor, multiple behaviors
Behaviors are great for handling single sprites. When you need to get a group of sprites to work together, then it helps to use an ancestor. The scrollbar in this movie is made up of five sprites:
The scrollbar scrolls the contents of a sixth sprite. All six sprites are controlled by a single instance of the script "Scroll Bar". Attached to the sprites in the scrollbar itself is a generic behavior named "Register". This registers each sprite with the Scroll Bar instance, telling the instance what role each sprite is to play. Each of these Register behaviors sets its ancestor to the same Scroll Bar instance.
Attached to the film loop sprite is a custom"View Port" behavior which also registers with the Scroll Bar instance. The View Port behavior converts #update events from the Scroll Bar instance into the movement of its internal sprites.
Customising the scroll bar
You will find a discussion on how the graphics used for the scroll bar need to be organised and named in the comments at the beginning of the Scroll Bar script. The members used to display the thumb will be created on the fly. You should provide graphics for the thumb at the smallest size that the thumb is to appear. The bar graphics should be 2 pixels high.
Even if the scroll bar is to be used horizontally, the graphics should be oriented vertically.
What if you want to have more than one Scroll Bar on the Stage at a time? When you drop a Register behavior on a sprite, it asks you for three items of information:
On beginSprite(), the Register behavior calls the Register() handler of the Scroll Bar script. It talks to the script itself, not an instance of the script. The Register() handler then uses the "Instance Broker" movie script to find or create an instance of with the appropriate ID.
To work together, all the objects that call the Register() handler must use the same ID. By default, this ID is set to #singleton. If you use #singleton as the ID, only one instance of the chosen script will ever be created. In this example, I've used #filmloop as the ID for the upper group of sprites and #viewPort as the ID for the lower one. If you type...
... in the Message window while the movie is running, you'll see how the Instance Broker stores the instances of the "Scroll Bar" script.
On endSprite(), the Register behavior de-register. When the Scroll Bar instance has no behaviors registered to it, it tells the Instance Broker that it is no longer needed, and the Instance Broker clears it from RAM. If you type...
... in the Message window while the movie is not running, you will see that the list has been emptied.
What if you need to set additional parameters for a given instance of a script? The Scroll Bar script is intended to be used both horizontally and vertically. (Only the vertical version has been fully tested). The
The current parameters of the current Register behavior are passed to the
Creating your own scripts
You can create your own scripts for use with the Register behavior and the Instance Broker. The Register behavior will only let itself be added to a sprite if the Instance Broker is available, and if there is one or more movie scripts with a Register() handler.
You can use the Scroll Bar script as a template for your own scripts. Most of my movie scripts with Register() handlers also have
Note that the Register behavior contains a
The "Get Handler" and "MX 2004 Conversion Broker" scripts contain handlers which are called by the Scroll Bar script. You may not need to include these in your own movies.