Event-Driven Graphics

A great strength of ActionScript is that execution is event driven. Things that happen in the outside world cause things to happen in Flash.

Frame Events

The most common event is that time passes. Of course, time passes rather continuously, but in Flash (as in video or film) time is broken into a stream of regular intervals called frames. In a typical Flash application there are 12 frames per second. Twelve times every second, Flash is interrupted by a frame event (more precisely, a frame start event), which starts a cascade of calculations. Anything that is in the process of moving must determine its new position and prepare to redisplay. This is how animation happens.

Each movie has a timeline. When a frame event occurs, it advances a pointer along the timeline to execute any new script or effect any changes scheduled for this frame.

Mouse Events

Frame events give Flash animation. Mouse events give it interactivity. When a user clicks a button, that is an event. It is in fact a series of events: First the cursor enters the button's hot spot (the Roll Over event). Then the user depresses the button (the Press event). Then the user stops pressing ( Release ) and moves the cursor away ( Roll Out ). All four events happen often within a half second, but each has a different meaning in the rapidly stabilizing language of user interface:

Roll Over:	What is this?
Press:	I think I want to perform this action
Release:	Yes, I do! I am committed.
Roll Out:	Oh. Well, now I am bored.

A good designer considers each event and supplies appropriate responses.

Button State

A button has three preprogrammed responses to mouse events. Each is a special named frame.

The   Roll Out  event  causes   gotoAndStop("Up") .
Roll Over  causes   gotoAndStop("Over") .
The   Press  event  causes   gotoAndStop("Down") .

Button Event Handlers

There are many more mouse events besides these three. Flash allows us to attach activity to any combination of events.

An event handler connects an event to actions. Event handlers are expressed as code fragments , not as keyframes. They are explicitly packaged as the code called by (for example) the Drag Out event or the <Escape> Key Press event ”or both.

There is a fundamental difference between button states and button events. Button state frames are formulated as part of the button object. This is, in effect, a prototype that we construct that lives in the library. Later, we place as many instances of this button in the application as we need.

An instance is not a copy. It is a new reference to the original unchanged prototype. This very powerful concept is at the heart of Flash architecture.

Since the button states are in the prototype, all instances we create (by dragging the button into the scene) share the same states. They behave identically, as long as their behavior is designed in the states.

But every button cannot do the same thing. Some buttons open and some buttons close. Some win and some lose.

To make this happen, Flash allows us to attach event handlers as Object Actions to the instance of the button. They can behave like the button states, and they can do more. They can identify seven mouse events, not just three, and they can attach any ActionScript to those events on that button. Button state frames (in the button's prototype) usually define the button's appearance and its dynamics ”how it looks, how it moves, and how it sounds. Event handlers (attached to the instance) usually specify what the button does, how it affects the rest of the world.