Macromedia Flash Article

Chapter 10, "Events and Event Handling," follows previous chapters that covered composing instructions for the ActionScript interpreter to execute. Now that readers are comfortable with telling the interpreter what they want it to do, this chapter explains how to tell it when to perform those actions. As Colin writes, "ActionScript code doesn't just execute of its own accord—something always provokes its execution. That something is either the synchronous playback of a movie or the occurrence of a predefined asynchronous event."

Synchronous Code Execution
"As a movie plays, the timeline's playhead travels from frame to frame. Each time the playhead enters a new frame, the interpreter executes any code attached to that frame. After the code on a frame has been executed, the screen display is updated and sounds are played. Then, the playhead proceeds to the next frame.

"For example, when we place code directly on frame 1 of a movie, that code executes before the content in frame 1 is displayed. If we place another block of code on a keyframe at frame 5 of the same movie, frames 1 through 4 will be displayed, then the code on frame 5 will be executed, then frame 5 will be displayed. The code executed on frames 1 and 5 is said to be executed synchronously because it happens in a linear, predictable fashion.

"All code attached to the frames of a movie is executed synchronously. Even if some frames are played out of order due to a gotoAndPlay( ) or gotoAndStop( ) command, the code on each frame is executed in a predictable sequence, synchronized with the movement of the playhead.

Event-Based Asynchronous Code Execution
"Some code does not execute in a predetermined sequence. Instead, it executes when the ActionScript interpreter notices that an event has occurred. Many events involve a user action, such as clicking the mouse, resizing the movie, or pressing a key. Other events happen without user intervention, such as a sound completing or an XML document loading. Just as the playhead entering a new frame executes synchronous code attached to the frame, events can cause event-based code to execute. Event-based code (code that executes in response to an event) is said to be executed asynchronously because the triggering of events can occur at arbitrary times.

"Synchronous programming requires us to dictate, in advance, the timing of our code's execution. Asynchronous programming, on the other hand, gives us the ability to react dynamically to events as they occur. Asynchronous code execution is critical to ActionScript and to interactivity itself.

"This chapter explores asynchronous (event-based) programming in Flash.

Types of Events
"Conceptually, events can be grouped into two categories:

• user events: Actions taken by the user (e.g., a mouseclick or a keystroke)
• system events: Things that happen as part of the internal playback of a movie (e.g., a movie clip appearing on stage or a series of variables loading from an external file)

"ActionScript does not distinguish syntactically between user events and system events. An event triggered internally by a movie is no less palpable than a user's mouseclick. While we might not normally think of, say, a movie clip's removal from the Stage as a noteworthy "event," being able to react to system events gives us great control over a movie.

"ActionScript events may also be categorized more practically according to the object to which they pertain. All events happen relative to some object in the Flash environment. We'll study objects in depth in Chapter 12,but for now, simply assume that content in Flash (buttons, movie clips, text fields, etc.) is normally represented as ActionScript objects and that we define events in relation to those objects.

"The core ActionScript objects that support events are:

• Button
• Key
• LoadVars
• LocalConnection
• Mouse
• MovieClip
• Selection
• SharedObject
• Sound
• Stage
• TextField
• XML
• XMLSocket

"For details on the specific events supported by the above objects, see the object's
entry in the Language Reference.

Event Handling
"Not every event triggers the execution of code frequently or affects a movie. A user may, for example, generate dozens of events by clicking repeatedly on a button, but those clicks may be ignored. Why? Because, on their own, events can't cause code to execute—we must write code to react to events explicitly. To instruct the interpreter to execute some code in response to an event, we create either an event handler or an event listener that describes the action to take when the specified event occurs.

"Due to its unusual evolution, ActionScript has four different ways of handling events:

• Event handler properties
• Event listeners
• Button event handlers with the syntax:

  on (eventName) {
    statements
  }

• Movie clip event handlers with the syntax:

  onClipEvent (eventName) {
    statements
  }

The rest of Chapter 10 takes a look at these event-handling mechanisms individually. It concludes with a couple of real-world examples—some simple applications that give you a sense of how flexible event-based programming can be.

You can download the entire version of Chapter 10 below:

You can also check out the author's site at moock.org/asdg/ or order the book from the O'Reilly Online Catalog.

This is a preview, beta chapter and may not reflect the final form or content of the printed book. Excerpted from ActionScript for Flash MX: The Definitive Guide, Second Edition. Copyright O'Reilly & Associates, 2002. All rights reserved.