flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kessler CTR Mark J" <mark.kessler....@usmc.mil>
Subject flash EventDispatcher and Event
Date Thu, 25 Jul 2013 11:56:45 GMT

    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;
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/statements.html#native


View raw message