3D
Dragging
Film Loops
Games
Geometry
Imaging Lingo
LDMs
Navigation
OOP

  Invaders
  Scroll Bar

Scripts
Shockwave
Sound
Sprites
Text
Xtras
Miscellaneous

Source:
Macintosh
Windows

Similar functionality with OSControl Xtra scrollbars

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:

  • an up arrow
  • an upper backing bar
  • a thumb
  • a lower backing bar
  • a down arrow

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.

Multiple instances

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:

  • role: what the role of the sprite is (up arrow, backing bar, thumb, ...)
  • script: what script to register with (in this movie, only "Scroll Bar" is available)
  • ID: what ID to use to identify the instance of the chosen script

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...

put InstanceGetList()

... 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...

put InstanceGetList()

... in the Message window while the movie is not running, you will see that the list has been emptied.

Additional parameters

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 GetCustomParameterList() handler in the Scroll Bar script interacts with the getPropertyDescriptionList() handler of the Register behavior, and allows you to set additional parameters. The best way to set these is via the Behavior Tab of the Property Inspector.

The current parameters of the current Register behavior are passed to the GetCustomParameterList() handler as a second parameter (not shown in this demo), so you can set different parameters for different sprites, depending on their role and other custom parameters.

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 GetRoleList() and GetCustomParameter() handlers, and I also use a private mRegister() handler which I customise for each script.

Note that the Register behavior contains a SetAncestor() public method which the Scroll Bar instance calls. From that moment on, all mouse (and keyboard) eventsare diverted to the instance that the behavior is registered with.

Additional scripts

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.