<< Chapter < Page Chapter >> Page >

Guarding against nonsensical combinations

How can you determine which combinations of classes and event types make sense and which do not?

As usual, your best friend is the documentation. For example, the ActionScript 3.0 Reference for the Adobe Flash Platform allows you to click on aclass name in the leftmost frame and read about that class in the rightmost frame. For every class that supports events, there is a hyperlink at thetop of the rightmost frame labeled Events . Clicking on that hyperlink will expose all of the event types supported by objects of the classbeing viewed.

SolidColor events

For example, objects of the SolidColor class support only two types of events:

Although you may be able to register event handlers for other types of events on an object of the SolidColor class, it doesn't make any sense to do so. The documentation tells us that there is no point in registering a MouseEvent.CLICK event on a SolidColor object.

The ACTIVATE and DEACTIVATE event types

Both of these event types are defined in the EventDispatcher class and are inherited by all classes whose objects have the ability to dispatch events (other than subclasses of the Proxy class that I am ignoring in this lesson) . They are both dispatched by the system as the result of certain runtime conditions that may be beyond the direct control of the user.I will explain a sample program later that uses these two event types.

The Flex Builder IDE is also helpful

Other useful tools for avoiding nonsensical combinations of classes and event types are the Flex Builder 3 and Flash Builder 4 IDEs. The IDEs provides popup hints at variouspoints as you type ActionScript code. In some cases, the popup hints will list the types of events supported by the object on which you are registering anevent listener.

The DisplayObject class

Of the large number of immediate subclasses of the EventDispatcher class, the one that will probably garner most of your attention in your earlyActionScript programming experience is the class named DisplayObject . According to the documentation:

"The DisplayObject class is the base class for all objects that can be placed on the display list. The display list manages all objects displayedin Flash Player or Adobe AIR."

Flex components

All of the objects with which the user can have direct interaction are instantiated from subclasses of this class. For example, I believe thatall of the components that appear in the Components tab in the Design view of Flex Builder 3 or Flash Builder 4 are subclasses of the DisplayObject class.

I also believe that all of those classes are grouped into packages such as the following:

  • mx.controls
  • mx.containers
  • mx.modules
  • mx.charts

There are about sixty-five classes in the Components tab of Flex Builder 3, and those are the classes that usually involve direct userinteraction. That leaves many more classes that support events that don't usually involve direct user interaction.

Events that don't involve direct user interaction

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Object-oriented programming (oop) with actionscript. OpenStax CNX. Jun 04, 2010 Download for free at http://cnx.org/content/col11202/1.19
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Object-oriented programming (oop) with actionscript' conversation and receive update notifications?

Ask