As of 2011, the Flash community has left absence of any particularly complete scrollbar solutions. Adobe’s scrollbar component is bloated, and a nightmare to customize. I’ve seen scrollbars that can be used for a fee, and some freely available, non of which are as customizable or feature-rich as they could be.
Scrollbars are a common thing for developers to fuss with, especially in the eleventh hour of a project. Everyone seems to be on a different page with them. Each developer has their own solution they’re familiar with, which gets tweaked slightly for each project.
The goal of this project is to get everyone on-board with a solution good enough to be relied on by all developers, and integrated into systems with little risk of future drawbacks.
TweenLite/TweenMax comes to mind as an example of an API that gets everyone on the same page with a particular aspect of coding. This system is not nearly as complex, but it is intended to go in that direction.
In their simplest form, scrollbars are just one or two proportions, a sliding element, buttons, and some mouse event listeners. But, there are lots of less obvious features that you rarely see incorporated into Flash scrollbars, because they can be pretty complicated, and until now, there was no API containing them all.
Here is a look at some of the features built in to Seven2′s scrollers:
- based around skinnability
- infinite implementations in one project
- lightweight footprint (approx. 13k)
- fast setup (as little as one line of code)
- code-based default skin (configurable, non-dependent)
- slider only (ScrollSlider) and buttons only (ScrollButtons) versions
- full version (ScrollBar) with configuration options
- auto, or manual updating of proportional dynamic thumb slider sizing with settable min/max length
- automatic hide and show upon content dimension changes (defeatable)
- configurable ease out via TweenMax (non-dependent)
- physics based easing via Seven2 critical damping engine (non-dependent)
- settable button scroll increment
- settable global defaults
- horizontal and vertical scrolling
- event dispatching
- unlimited viewport masking capability (gradients, scrollRect, etc.)
- full scroll panel and window api (beta)
- static settable enter-frame dispatcher to accommodate global site pausing
- infinite scroller designs and configurations in one deployment
- mouse wheel functionality (implementation may change)
Documentation is in progress, both in ASDoc, and a getting-started overview, available here.
The most important aspect of the scrollers is skinning. Skin symbols can be whatever you want. All you have to do is name them properly, and make sure their registration points are all consistent with the requirements.To be flexible, the scrollers allow a few ways to pass in your skin collections. Skin collections can exist as members of an Object, or a DisplayObject, that gets passed to the constructor. As an alternative, you can also have your skin pre-assembled inside your scrollbar, so that you can place it on the timeline, in the Flash IDE, so that you can work around a visually represented scroller, and save a few lines of code, if you prefer.
The second most important aspect of the scrollers is updating. Content can change at any time, whether it be from a page change, asynchronous loading, or animation. It may cause the scrollable content bounds to change. There are a few aspects of the scroller that need to respond to this kind of event, including displaying correct proportions, and making sure the content is still in-bounds. Sometimes the programmer can predict when this will happen, sometimes not. The scrollers provide you with ways to update them for each situation. Calling ScrollController.update() will manually update content when it is known that a change has occurred. For when this cannot be predicted, the scrollers provide auto-update (ScrollController.autoUpdate()), a way continuously detect changes, by recursively checking for a change to bounds of the content. Auto-update is a nice feature, but it can be a drag on system resources, as it uses an enter-frame event listener continuously. For this reason, it is off by default to encourage developers to update scrollers manually, at the point that content is known to be fully populated. This can be a source of confusion, so I sometimes consider reversing this decision.
There are many more features in these scrollers, and there are more to come. The getting started guide should give you an understanding of the scrollers to be able to set them up fairly quickly on your own, but feel free to bug me if you get stuck.