Hi Mark, I'm a bit lost on the context here. The Flash Player is more or less implementing the W3C DOM Event Specification. Are you looking to enhance it? If so, why? A whole group of people over at W3C decided this API set was sufficient. Or did I miss where they are also updating the specification?
If this is related to the attempt to know who is listening for events on an object, keep in mind that I've seen folks want to know that in order to get all of those listeners to call removeEventListener, but I've never really understood why, since those listeners do not cause a memory leak of the object being listened to since the only reference is from the object being listened to, to the object that is listening. -Alex On 7/25/13 4:56 AM, "Kessler CTR Mark J" <mark.kessler....@usmc.mil> wrote: > > Ok I've spent a little bit of time looking into both the flash >EventDispatcher and Event. To get a good picture of how they interact >and target the DisplayObjects. They have quite a few missing properties >and communicate without using public methods. > > Turns out they just execute code inside the player itself natively >[1]. So my observations show the missing properties/methods are actually >controlled in the player which explains a few things. Giving a small >example from the flash.events.Event. > > > When using the preventDefault on an event and be able to check if >it's prevented... > >public native function preventDefault():void; >public native function isDefaultPrevented():Boolean; > > > However simple things like being able to see if propogation has been >stopped, are not present but still being used internally to the player... > >public native function stopPropagation():void; >or >public native function stopImmediatePropagation():void; > > > Since the method dispatching the events is in the player and has >access to the properties that aren't in the event or eventdispatcher. > >private native function dispatchEventFunction(event:Event):Boolean; > > > What this means is your two choices for coming up with a more >controllable EventDispatcher. > >A. Override the EventDispatcher methods and run a parallel set of >methods and properties while still calling the existing EventDispatcher >parent (super). It works well, but seems inefficient to be doing >everything twice (overridden and super both doing looping operations). >Less inefficient if using a Dictionary or Map to store the event handlers. > >B. Create a new FlexEventDispatcher / IFlexEventDispatcher and modify >something like the Flex Events and FlexSprite to work with the new >dispatcher. Which seems like an uphill battle to do lots of little >overrides on the existing base components we have access to. It would >only have a functional benefit if a set of components would start using >it as part of its base. > > > Looks like Adobe has a tight grasp on this. Anything else will >always be a work around. The only long term way around this type of >stuff would be to change all the base components and start a new >component namespace that starts using a base of all Apache Flex made >classes (no small task in itself). > > >[1] >http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/stateme >nts.html#native > > >-Mark >
