Thanks Alex, so I guess anytime we want to fully support capture phase
listeners we should try to ensure a unique value for our event const
values?

Is there any reason the framework did not try to use unique values for
event types?

Thanks,
Ben


--- In [email protected], "Alex Harui" <[EMAIL PROTECTED]> wrote:
>
> capture phase listeners cannot assume the type since child objects may
> be conversing with the same event type .
> 
> ________________________________
> 
> From: [email protected] [mailto:[EMAIL PROTECTED] On
> Behalf Of ben.clinkinbeard
> Sent: Monday, August 27, 2007 6:26 AM
> To: [email protected]
> Subject: [flexcoders] Re: Event collision- is this a bug or expected
> behavior?
> 
> 
> 
> bump
> 
> --- In [email protected] <mailto:flexcoders%40yahoogroups.com>
> , "ben.clinkinbeard"
> <ben.clinkinbeard@> wrote:
> >
> > I am noticing some odd behavior adding capture phase event listeners
> > to TabNavigator. While trying to answer another question
> > (http://tech.groups.yahoo.com/group/flexcoders/message/84929
> <http://tech.groups.yahoo.com/group/flexcoders/message/84929> ) I
> > noticed that this code:
> > 
> > tabNav.addEventListener(IndexChangedEvent.CHANGE, onChange, true);
> > 
> > will cause a RTE if onChange()'s event arg is typed as
> > IndexChangedEvent. As it turns out, listening to the capture phase
> > causes the listener to receive a regular Event object whose target is
> > the actual tab you clicked on. Listening to bubble phase produces an
> > instance of IndexChangedEvent whose target is the actual TabNavigator,
> > which is what I would think is the expected behavior.
> > 
> > I am assuming the problem has something to do with the fact that
> > IndexChangedEvent.CHANGE and Event.CHANGE both evaluate to "change".
> > Is this expected behavior? I can't quite get my head around why it
> > would be but that doesn't mean its not. I actually had this problem
> > with a custom component the other day and ended up changing the
> > event's string value to avoid the collision.
> > 
> > Thanks,
> > Ben
> >
>


Reply via email to