OS NonLinear




	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.