go to previous page

- discuss this tutorial -

go to next page

IV. Events

One of the new features in the component architecture is the event system (mx.events.* package). Not only has Macromedia created a good event system to use, but they have also automatically created many events that your component should support. When your component sub-classes the UIComponent, it will automatically have all these events.

Event Implemented by Sub-classing UIObject:

• resize : This event occurs when a user calls setSize(). It is implemented in the setSize() function of UIObject.
• move : This event occurs when a user calls the move(). It is implemented in the move() function of UIObject.
• draw : This event occurs every time the component’s draw() function is called. This usually occurred initially when the component is drawn and on subsequent times when the component is invalidated. It is implemented in the redraw() function of UIObject.
• reveal : This event occurs when a user sets a component to visible = true. It is implemented in the setVisible() function of UIObject.
• hide : This event occurs when a user sets a component to visible = false. It is implemented in the setVisible() function of UIObject.
• load : This event occurs when a component is loaded. It is called implicitly by the player when a MovieClip is loaded.
• unload : This event occurs when a component is unloaded. It is called implicitly by the player when a MovieClip is unloaded.

These events are just the start; you can even dispatch your own custom events

Custom Events

When developing components, it is good practice for your component to contain some custom events. These events will help a developer make better usage of the component. When first building a component, I recommend you spend a bit of time thinking of what events you may want to implement, since the actual implementation process is quite simple. This is yet another major benefit of using Macromedia’s architecture. Imagine having to write your own even system, even if reusable, for every component you build. Moreover, imagine what a nightmare it would be for every component developer out there to use their own system. In this article we won’t be discussing the public API for the even system, but if you have used any other component based of the version 2 architecture before, you will already be familiar with it. Briefly, your component will support addEventListener(), and removeListener() as other components do.

Mix-in of UIEvent Dispatcher

If you take a look at UIObject, you may not see any of the event system implemented there. The reason for this is that it is implemented through mix-ins. Mix-ins are a way of adding functionality to a class. It is possible because of ActionScript’s loose nature. If you take a look at the UIObject class, the only trace of the event system you will see is the few non-implemented function declarations dispatchEvent, handleEvent, removeEventListener, and addEventListener. The method of adding the event system to an Object is through calling mx.events.UIEventDispatcher.initialize(theObject) for UI Items. This method is not present in UIObject, instead it is located in the UIObject extensions (mx.core.ext.UIObjectExtensions) and is called by the skins initializing. It’s important to keep this in mind if you find that your component does not receive the implementation of EventDispatcher.

The dispatchEvent(eventObj:Object) method

You will use the dispatchEvent() method for your custom events. When you call this method, all listeners of the event will be notified. The event object is required for the event system to notify the correct listeners and will also be sent to all the listeners of the event. Commonly you will create an anonymous object with the type property equal to the event. Example: dispatchEvent({type:”change”}) will notify all listeners of the change event. The event object also includes a target property. If you do not provide a target property in your event object, it will default to the a reference to the current component. You also are able to send other properties with the event object in this way dispatchEvent({type:”change”,oldValue:someValue}). This will provide all listeners with an added property “oldValue” that you provided when calling dispatchEvent().

The UIComponent Base Class

So far you have covered the UIObject class. Although the UIObject class provides us with a lot of functionality, there is yet another class that you can use as the base class for your component. The UIComponent class is a subclass of UIObject, because of this almost all of the information covered about UIObject applies to UIComponent. UIComponent is essentially UIObject with the addition of focus management, the enabled property, user interaction, and smart resizing. For the remainder of the article you will cover these added capabilities.

A lot of this additional functionality is handled automatically for you by the architecture. The focus management does not usually require extra effort unless your component requires some additional logic to handle more complex situations the framework does not handle on its own. The addition of user interaction capabilities is similar to focus management and is also usually handled by the framework.

Some Changes to Note

It is important to note at this point that the tabEnabled property is set to true wherein in the UIObject class it was not. This is required for our component to receive focus and one of the reasons why UIComponent supports focus management.

Smarter Resizing

In UIObject, we covered the size() method. By design, UIObject defaults to resizing by adjusting the scaleX and scaleY property values to make sure the component is always as large as the bounding box. With UIComponent this is not the case. Instead you are required to implement size() and use your own resizing algorithm which usually is smarter than just simply adjusting the scaleX /scaleY.

go to previous page

- discuss this tutorial -

go to next page