0 Replies Latest reply on May 25, 2007 9:19 AM by mosesoak

    Possible bug, at least serious problem, in the AS3.0 event architecture

    mosesoak
      Event bubbling causes a compiler error when it should not.

      High up in the display list, a listener has been added for TypeBEvent which extends TypeAEvent.

      Lower in the display list, a different object dispatches a TypeAEvent, and sets bubbling to true (and possibly, cancellable to false).

      A Type Coercion error (#1034) results! The listener receives the bubbled event which is of the same type as the base class of the handler event type. The event object "cannot be converted" to the TypeBEvent it is receiving.



      Circumstances

      This situation came up in a real Flex project, where a video player that had been loaded as a module within another module dispatched a PROGRESS ProgressEvent, and a listener had been added to the higher level module for its ModuleEvent PROGRESS event, ModuleEvent subclasses ProgressEvent. The video player bubbled its event, and the compiler threw this error: "TypeError: Error #1034: Type Coercion failed: cannot convert flash.events::ProgressEvent@1f2de0d1 to mx.events.ModuleEvent."

      This compiler error does not make sense from a developer perspective, because it means any class lower on the display list can break the player (not the program, the player) simply by dispatching an event.

      Our team lost a great deal of (expensive) time trying to locate the source of this problem, since nothing about the compiler error – including the stack trace! – indicated the high-level class. In fact, the module developer didn't know anything about the high-level class which was compiled to a swc library, and the event being dispatched was in the flex class library, so neither end of the problem was very visible. Because the error only pointed to the video player class the developer naturally went into the flex classes first and tried to solve the problem in their scope before finally giving up and bringing the problem to others on the team.

      Truly a case where the software defeated team workflow.


      Our conclusion

      We love the new event framework but, this seems to come pretty close to qualifying as a bug. The high-level event listener simply should NOT have received, then choked the player on the bubbled base-class event. It should either receive it or not. If it did receive the event, the code in the handler could check whether the event target was appropriate... but instead the player breaks and does not provide any clue as to where, it only indicates the dispatching class as a culprit. Even short of fixing the problem, improving the error message so that the receiving event handler is clearly implicated would be a start.

      Again I am of the opinion that this compiler error should not take place at all because the top class subscribed specifically to the subclassed event type. A bubbled event that breaks the player due to an unrelated listener is just a huge black hole, especially when multiple developers are working on different tiers of a program.

      Could we get a reply from someone at Adobe on this issue?

      Thanks very much,
      Moses Gunesch