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

Question

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

Answer 1

If you create a metadatatype with a single metdata block, and you reference that in your vm/cm cell attribute using a *one* based index, Excel seems to see the link and it honors it when saving the spreadsheet.
So, I ended up with something like:
<c ... cm="1"/> (I'm dealing with cell metadata, but the concept is equivalente to value metadata)
<metadataTypes count="1">
  <metadataType name="MyMetaType" .../>
</metadataTypes>
<futureMetadata count="1" name="MyMetaType">
  <bk>
    <extLst><ext
uri="http://example" xmlns:x="http://example"><x:val>87</x:val></ext></extLst>
  </bk>
</futureMetadata>
<cellMetadata count="1">
  <bk><rc
t="1" v="0"/></bk> <!-- this is what gets referenced as cm=1 on the cell -->
</cellMetadata>
Hope this helps.