Imaging Lingo Text Scrollbar

August 2, 2001
by Steve Bullock

Over the years, our company has completed hundreds of different Director movies that included scrolling text cast members of one sort or another. The single most frequent use of these scrolling text members has been to provide instructions to players within a Shockwave game - often on screens which are heavily animated and interactive.

If my memory is accurate, Macromedia changed a lot of the characteristics of their text cast members with Director Version 6.0; and most all of these changes were for the better. But one of these new characteristics (one that persists through Director 8.5) is extremely flawed and quite annoying - the standard Director text scrollbar. This scrollbar is drawn Direct-To-Stage and its flaws include:

1. You can't drag or animate other sprites over the top of the scrollbar, no matter the sprite channel or the Z-Order (locZ) setting of the sprites. They will always go under the scrollbar, even when they move on top of the text member itself.
2. You can't slide the text member on and off the Stage if it is supposed to appear "under" anything (like a border). Again, the scrollbar will always appear on top.
3. When you use a transition to go to a frame containing a scrolling member, the transition will often look broken because the scrollbar will be drawn before the transition takes place. Any client seeing this will think that you messed up the programming.
4. When the scrollbar is clicked, all animation (and frame head movement and events) in the Director movie halts while the mouse remains down. This is particularly noticeable when a user is grabbing and moving the slide button or scrolling continuously using the arrows. I realize that this was done by Macromedia programmers to facilitate faster redraws of the text member (so it will scroll faster), but it still is a poor overall design.

Until recently, we worked around these by constructing a single text sprite's scrollbar in four sprite channels devoting:

1. a sprite channel to the up button graphic;
2. one for the down button graphic;
3. one for the bar graphic;
4. and one for the thumb/scroll button graphic.

Each of the four sprites would have an appropriate behavior. Hence, we were carefully placing four sprites on stage, then attaching four behaviors every time we needed to make a "proper" scrollbar. This gets tiresome; but "a man's gotta do what . . ." you know.

Enter Imaging Lingo, probably the single most outstanding and underutilized (by many programmers) feature of Director 8.0. Recently, I spent some time putting together a behavior that would render a system-style scrollbar in a single bitmap; later, I refined the behavior to cover a wide variety of custom graphics scrollbars as well.

View the sample Shockwave movie.

You'll find the behavior in the D8 movie you can download here in Windows or Mac formats.

To use the behavior, you simply need to . . .

1. have bitmap cast members for the four key scrollbar elements (up and down buttons, bar, and scroll button),
2. place a #fixed (not #scrolling) text member in a score channel,
3. create a placeholder bitmap cast member and put it in a different sprite channel,
4. attach the behavior to the placeholder and set the behavior's properties.

Then, in the behavior's beginSprite handler, the scrollbar is automatically rendered to the placeholder bitmap and the scrollbar sprite is automatically positioned and sized on the right edge of the text member sprite. That's all there is to it.

on beginSprite me
  pSprite = the currentSpriteNum
  pMemb = sprite(pSprite).member
  pTextMemb = sprite(pTextSprite).member
  pTextMemb.scrollTop = 0
  pCurrScrollPercent = 0
  pSlideClicked = 0
  pSlideOffsetV = 0
   -- The next 4 lines store the images of the four elements members in properties
  pUpArrImage = pUpArrMemb.image.duplicate()
  pDownArrImage = pDownArrMemb.image.duplicate()
  pBarImage = pBarMemb.image.duplicate()
  pSliderImage = pSliderMemb.image.duplicate()
  SetLocationsAndDimensions me
  SetArrowClickDelays me
  SetInitialImage me
end

I won't dwell on the nitty-gritty of the Lingo of this behavior here as it is fairly well commented within the behavior itself. But a rundown of this behavior's features might encourage you to use it in your next project.

1. The behavior will accommodate virtually any set of graphics you wish to use for the scrollbar elements. Go with graphic elements that mimic system scrollbars (a couple of sets of these are included in the demo movie) or roll your own with some fancy custom graphics.
2. The scrollbar has cursor changes for rollover and grabbing the scroll/thumb button. I'm a big fan of cursor changes for all clickable elements. The cursors disappear if the text is too short to scroll. The cursor commands can easily be commented out of the behavior if you prefer a scrollbar with no cursor changes.
3. A click sound may be assigned to scrollbar mousedowns.
4. It is not Direct To Stage so it doesn't ruin transitions or animations that may move over it.
5. It does not halt frame head movement, Lingo event processing, or animations when a user is clicking or holding the mouse down. Scrolling does slow the frame speed a good deal - mostly because the time that Director still needs for rendering anti-aliased text to screen - but it doesn't halt things.
6. By default, the behavior sizes the scrollbar height to the exact height of the text sprite and it snaps the scrollbar to the right edge of the text sprite. But if you want the scrollbar to be taller or shorter than the text sprite, you can specify a pixel difference (from the text member height) and it will size itself accordingly and then vertically center its position on the center of the text sprite.
7. You set the scroll speed for clicks on the up and down arrows. Scroll in big chunks if you have a really long passage of text or in really small chunks if you want a slow-smooth flow. And the scroll arrows respond just like system scrollbars: they scroll once, pause for a bit and then begin a continuous accelerating scroll.
8. When using custom graphics, sometimes it looks stylish to have the "bar" area float between the up and down buttons with a transparent gap between the bar and buttons. There is a "Gap" setting in the behavior that will do just that.
9. The behavior relies on Ink Settings to draw the down states of the scroll arrows and the scroll button. There are separate, settable properties for the ink of each. Because our company does a lot of bandwidth-friendly Shockwave games, we use ink changes in place of up and down state graphics whenever we can -- to minimize file size. A corrolary of this is that you will only need 4 basic graphic elements for the scrollbar (rather than 7). Experiment with different inks for the button down states and you will probably find a good one. But if you can't, adding a bit of Lingo to swap out images of down state graphics for the up state images (rather than the ink changes) should not be that daunting a task. And it would be a good exercise for those that haven't used imaging Lingo as yet.
10. The behavior does not require that you place any behavior whatsoever on the text sprite. But if you want the text sprite to know when it has been scrolled (so that it may react in some way), there is Lingo in the behavior already that will do just this.

I hope this behavior helps cure any scrolling text annoyances you've encountered and that it helps you make some most creative scrollbars.

Copyright 1997-2024, Director Online. Article content copyright by respective authors.