>> In my project, this EventDispatcher managing all the Sprites. Is there a better way of managing all the displayObjects from one class, other than having instructions come from an EventDispatcher?
See the example I posted - you just have to extend on it. If you choose MVC as a pattern like I like to do, you have a controller class which listens to display objects and has handlers to uh, handle them. Jason Merrill Bank of America Global Learning Learning & Performance Solutions Join the Bank of America Flash Platform Community and visit our Instructional Technology Design Blog (note: these are for Bank of America employees only) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mendelsohn, Michael Sent: Thursday, March 18, 2010 10:32 AM To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening Thanks for the responses everyone! > Yes, and what I am saying is, that architecture is wrong. You don't create instances of EventDispatcher and then put Display object inside of them. OK, it seems I've violated a golden rule about bubbling. My EventDispatcher obviously isn't on the display list, so it's the end of the road for that Sprite's event. For this project, I am passing along a custom event object like a hot potato, however inefficiently. Live and learn. But, there's a broader question I'd like to ask. In my project, this EventDispatcher managing all the Sprites. Is there a better way of managing all the displayObjects from one class, other than having instructions come from an EventDispatcher? - MM _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
