AS 3: The Event Framework
Mar 15th, 2008 by Leo Geis
Most aerial photographers-even if not pilots-are very familiar with flight in controlled airspace. In order to keep track of all the aircraft in the air, Air Traffic Control will require an aircraft to report entering airspace, report on site at the subject, report leaving the site, report when they see traffic (other aircraft), and report leaving airspace. What you don’t actually tell the Controller over the radio is reported automatically, such as your altitude, speed, direction of flight and position at any time (RADAR). All of this is intended to provide the positive control of air traffic. You need positive control of your ActionScript applications, too.
In order to help you maintain control over your Flash application, Flash Player will send out a signal whenever any predetermined things happen. Those predetermined things are events (lower case “e”), but those signals are actually Objects-specifically, Instantiations of the Event Class or a particular DisplayObject Class…more on that later.
Various Classes have their own Event Types that they pass on to their Instances: This is the list of Event Types for the SimpleButton Class. There’s no need to be intimidated-these are simply “tools in the drawer.”
Aside from the Event Types native to Classes, there is also a flash.events Package. The EventDispatcher Class is the Superclass (”parent”) of the DisplayObject Class, and it is through that relationship that all DisplayObject Instances maintain their native Event Types.
The EventDispatcher Class has “activate” and “deactivate” Event Types. Just tuck that one away for now.
dispatchEvent() is a Method (thus the lower case first letter) of the EventDispatcher Class, which is an ancestor of the DisplayObject Class-therefore, all Instances of Classes that extend the abstract DisplayObject Class have the ability to call their inherited dispatchEvent().
The Mouse and Keyboard Classes do not inherit from the DisplayObject Class-they are descendants of the Object Class, which does not inherit from the EventDispatcher Class (it’s actually the other way around-check the heirarchy!) so they don’t have native Events. The flash.events Package contains MouseEvent and KeyboardEvent Classes for them to employ.
It’s starting to make sense, now…isn’t it? There’s actually a very reasonable and methodical construct to the Flash Event Framework, and if one can recongize that strategy a great deal of memorization may be obviated.
You have more than enough guidance on the AS syntax for creating Event Handlers in Flash Help (F1), online resources and books in print-there’s no sense in replicating that here. Let’s explore the the mechanics of the Event flow in order to understand the logistics.
When an Event occurs:
- A dispatchEvent() call to the appropriate Event Class (e.g. MouseEvent or particular DisplayObject) is made…
- …producing an Event Object…
- …which contains information about the event that prompted its creation (as a Variable/s)…
- …and which is passed as an Argument (Parameter) to any Event Listeners “registered” via addEventListener with the Object that originated the dispatchEvent() call…
- …which calls whatever Function/s you have specified as responses to that Event.
At least, that’s the way I understand it. I’ve never actually seen this happen!
Event Types are frequently contained in an Event Class as a Constant (an unchanging value indicated by using all capital letters in its identifier):
CLICK, DOUBLE_CLICK , MOUSE_DOWN, and some other MouseEvent Class Events are here indicated by Constants.
The EventDispatcher Class also provides Methods for removing Event Listeners when they are no longer needed. Those Methods are provided to other Classes that extend EventDispatcher and to their Child Classes.
Finally, it’s important to understand how Event Objects are passed around through the Display List (Event “Flow”).
Briefly, when an Event Object is dispatched (or “fired”) by the Flash Player it is navigated from the Stage up through the Display List hierarchy to the Object that instigated its dispatchEvent(). This allows each Parent Object in the Display List access to the EventObject-in essence, simply “letting everyone know what’s going on” so that (e.g.) in the eventuality of a very busy Display List less micromanagement of Events will be necessary.
The distribution of the Event Object from the Stage to the very last Object prior to the Target that called dispatchEvent() (now you can understand its title, “Target” a bit better?) is called “Capture.”
Once the Event Object reaches its Target it is formally dispatched from it. If an Event Object is external to the Display List (e.g. it is a MouseEvent or KeyboardEvent Event Object) this “Target” phase of the Event Flow process is not accompanied by Capture or subsequent “Bubbling.”
“Bubbling” is the process of an Event Object working its way back down to the Stage from its dispatchEvent() Object (Event Target), notifying everyone of its arrival along the route.
“Joy at the start,
Fear in the journey,
Joy in the coming home.”
Dan Fogelberg, Along the Road, 1980
Event Listener Functions allow you to control certain aspects of their activity such as in which phase of the Event Flow Event Objects are actually listened for, their relative priority, and how persistent the Event Listener will be in the viewing computer’s memory (memory management becomes critical in some Flash applications).
L