AS3 – custom event classes or inspectable properties
In AS2 I used a custom Broadcaster class that allowed you to fire an event and pass along an object to the listeners. As I transition and get comfortable with AS3 and the improved event model I have come across a question I cant seem to find a clear answer for.
I have been trying to decide what is better/proper practice when it comes to Events in AS3. Is it better to extend and create custom event classes that contain gettable/settable properties to be passed along with the event? Versus, dispatching a more generic event and have the listener reference back to the object that fired the event to obtain a property value? Is the pain of creating multiple Event classes going to benefit me in performance? Is there a hit to the performance for a listener to receive an event, and reference back to a target to get the property values it needs?
Any feedback on this subject would be greatly appreciated

November 13th, 2007 at 3:14 pm
Custom event classes are useful to store “snapshot”/dto information about an event.
If you have multiple listeners subscribed to an event, and then first listener modifies the target during the event dispatch process. Then, the other listeners may not act correctly once they receive the event because the targets state is different to when the event was first dispatched. Also, you may end up compounding the event stack which isn’t going to be nice.
November 13th, 2007 at 4:29 pm
Thanks for the response Alex. That makes a lot of sense!
November 13th, 2007 at 11:25 pm
You may want to take a look at this: http://evolve.reintroducing.com/2007/10/23/as3/as3-custom-events/
I fought with the same thing when migrating to AS3 and that was my rather painless solution. I’m not as technical as some other people and I try to make things as understandable as possible, but that seems to be working for me really well thus far.
hope that helps.
November 14th, 2007 at 8:27 am
I believe, it’s better to retrieve the additional data from the object that has dispatched an event. The reason is that whatever the case the object has to have public properties, indicating its current state. Complex event classes with numerous properties are relevant when it comes to creating reusable event classes as for me. In simple cases you are just creating one more unnecessary layer of the code and you need to maintain it. Moreover, you have to change the event class constructor signature while keeping bubbles and cancelable parameters.
January 18th, 2008 at 2:17 pm
CRAP!
I have not gotten ANY events to work. If you have to call everything from the main timeline then how do you control ANY individual elements?!
I have a MovieClip on the Main Timeline with bubbles going up. When they reach the top, they release their enterframe listener and re move themselves – I need them to advance a counter – a SIMPLE thing – but there is NO way I have found to do it. It’s so stupid that you can’t use paths like you could in 2.0.
It wouldn’t be so bad if the custome events actually WORKED but I have tried and failed every time!
I am so frustrated – what do I do now?
B
January 18th, 2008 at 7:27 pm
@Ben – Hard to say without an fla but you can still reference parent (just no underscore with AS3) to advance a counter variable stored inside the MovieClip that houses the bubbles. It’s also worth mentioning that not everything HAS to be called from the main timeline, you can still have scripts on nested timelines as you have always done. The only real change there is syntax. Hope that helps.
July 14th, 2008 at 5:00 pm
Can you give an example of how you would reference the original object that dispatched the event? A global variable will not work for me in this instance as I could be dispatching multiple events, each time overwriting the global variable. Is “parent” a valid member of an Event object?
July 14th, 2008 at 5:20 pm
@tupakapoor you can reference the target by inspecting the target property of the event object. for example, in your listener method you could do something like:
private function myListener(evt:Event):void {trace("The object that dispatched this event is " + evt.target)
}
Hope that helps,
-Dave
October 9th, 2008 at 5:00 pm
Hi Dave,
Personally, I usually like to create an event with all the needed properties in it, I then only make getter methods so the properties are read-only – this reminds me not to try anything clever with them
– (the properties get initialized in the Event’s constructor).
Having the event be read-only makes your objects less coupled, which is a Good Thing. However, it sometimes means that you spend ages creating events with lots of properties that just mirror the object that sent it, which is a Waste Of Time.
All in all, I’m still fairly undecided and play it by ear, if the event sending object wants to be updated because of the event I just use the reference, otherwise I have the relevant properties in my custom event.
If you ever find out the best method to use, please let me know!
Sam.
October 28th, 2008 at 5:32 pm
I don’t think there is one all encompassing “best method.” Different problems warrant different solution, and even then there are many different solutions to any one problem.
For the most part thought, I agree with Alex in the first comment. If your object dispatches a custom event it can create a DTO which contains only the information relevant to that event and pass that along with it. Multiple listeners can pick up the DTO and do whatever. This way they leave the dispatching object alone.
It may seem like more work to some people but it’s better design in my opinion, but as I stated above it’s not the definitive answer.
I might write a bit in my blog about custom events and DTOs if anyone is interested.
Joony