This is going to be a very simple example of how to dispatch an event. In actionscript 3, you dispatch an event by extending the EventDispatcher class. I’m not going to get into a big complicated explanation right now, but I will show you a couple of simple examples.
One good thing about the Sprite class is that it already extends the EventDispatcher class, so if you are working from your document class, or your class extends Sprite/Movieclip, you can use this anywhere in your class:
1 2 3 4 | // Declare at the top... public static const customEvent:String = "customEvent"; // ... Somewhere in your class... dispatchEvent(new Event(customEvent)); |
Let’s say for example you have the following class:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | package{ import flash.display.Sprite; import flash.events.EventDispatcher; public class Cat extends Sprite{ public static const MEOW:String = "meow"; public function Cat(){ } public function meow(){ dispatchEvent(new Event(MEOW)); } } } |
Now create an instance from your timeline:
1 | var cat:Cat = new Cat |
next:
1 2 3 4 5 6 | cat.addEventListener(Cat.MEOW, doSomething); cat.meow(); function doSomething(event:Event){ trace("The cat is hungry!"); } |
Ok, so this really doesn’t do anything useful, but you can see how you could use this idea to broadcast events from your objects. This is by no means comprehensive, but I have noticed that this simple concept has eluded a lot of people. Later I will write a more robust tutorial showing how to extend the EventDispatcher class and do some cool stuff.







Nice, I didn’t know of this. It would be useful for event listeners and all.
I see a wide variety of useful scripts someone could make with this.
You can have your class broadcast all kinds of events for a variety of different situations and listen from other classes. It is especially useful when you need to wait for something to finish before starting something else. (such as my flashPHP class). It broadcasts a “ready” event after it receives the data from php.
Using a simple String like this is bad practice.
It leaves the dev wide open for typo’s, guessing what they need to listen to (you should add metadata to describe what events will be dispatched) and skips all type checking on the event
Tink, you make a couple of great points and you are absolutely correct.
Technically I probably should have created a new custom event class, such as the one in your example (which is very good, everyone check it out here:
http://www.tink.ws/blog/custom-events-in-as-30-dont-forget-to-override-the-clone-method
For my blog I try to create the most simple of examples so that people can get a grasp of concepts that they haven’t been able to get their heads around. Unfortunately sometimes it is at the cost of best practice. Thanks for your comment!
I made a couple changes to make it a little more compliant
Thank you so much for writing this. It’s helped me with writing a custom XML Parser. Thanks a lot! very simple to understand