I'm thinking I'm probably extra stupid, but I kind of got the impression from the Event handling docs that if you wanted to send out your own events, you had to have your own events class. It seemed to me there was something magical in the constants defining event names in your events class that somehow made the events so named "your" events. It turns out that if you want to dispatch an event "this is an event" then it really is as simple as
dispatchEvent(new Event("this is an event"));
Then all you have to do is add an event listener for "this is an event". There's no more magic to it than that. The event just needs to be called the same thing on both sides, and that is what the constants make sure of. But they're not required.
Now, if you want to pass more information in an event, such as whether a click on a Multiple Choice Question is right or wrong, then you'd need your own Event class. But for simply broadcasting an event you know is yours, you just send out an event as above. Duh.
I figure most people reading this are not as "challenged" as I am, but hopefully this helps someone anyway.
Update 7/3/2008: When a component is dispatching events, it should also "announce" what events are available on it with an Event metadata tag, such as [Event (name="thisIsAnEvent" type="flash.events.Event")]. This allows you to use it in MXML without a compiler error. I honestly don't know whether multi-word event name, as stated in my original example, would cause an error or not.
Posts
5 comments:
Nice! But why you should want to dispatch an event if you can't send information associated? I think you will allways need your custom event class.
If you know an event of type "this is an event" is coming from singleton type classes or components where you know there is only one instance around and therefore you don't have to pass around information you can directly get from the instance. Now, whether that is good practice or not is another question, it boils down to when the deadlines are and how much time you've spent trying to figure out Events in Flex ;).
Thanks for catching this old comment that had slipped through the cracks. Here's my take on it....
Typically, Singleton classes are not on the display list, so you have to listen directly to them in order to register for their events. So you can be very, very sure that the information in the event handler is coming from that object, unless you've registered for a lot of "this is an event" handlers coming off of other objects, and why would you? ;-)
In most cases, you're registering for an event on a particular objet (or at least I am) with a given handler even if it is not a Singleton, so I'm normally pretty sure where my event is coming from. In the rare instance where that is not true, there are many ways to verify the identity of the object that generated the idea.
My personal practice is not to send information around in events that can be captured in other ways, as I feel it creates additional dependencies to use strongly typed events (both classes must contain a reference to the custom event class). Instead, I usually make that information available for inspection, and view events mostly as a notification that something has changed that whoever registered for the event should look at.
Smart. very smart. Works like a charm. Oh, you need a comma in the metatag info [Event ( name="myEvent" , type="flash.events.Event" )]
Nice post.. you know i was also of the impression - you had to have your own events class ... Thanks for clearing that up ..
Post a Comment