Fair enough, I didn't really think about MXML ugliness. Thanks for
sharing your approach, I was leaning that way but its good to get some
validation.

Ben


--- In [email protected], "Alex Harui" <[EMAIL PROTECTED]> wrote:
>
> Too hard to manage.  Can you imagine having to apply to us for an event
> name in order to prevent possible collisions?  You could decorate names,
> but these names show up in MXML, so that's not fun 
> <mytag benclinkinbeardChange=".." >
>  
> Capture phase is rarely used.  My handlers look like:
>  
> captureHandler(event:Event)
> {
>     if (event is ItemChangedEvent)
>     {
>     ,,,
>     }
> }
> 
> ________________________________
> 
> From: [email protected] [mailto:[EMAIL PROTECTED] On
> Behalf Of ben.clinkinbeard
> Sent: Monday, August 27, 2007 11:35 AM
> To: [email protected]
> Subject: [flexcoders] Re: Event collision- is this a bug or expected
> behavior?
> 
> 
> 
> 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] <mailto:flexcoders%40yahoogroups.com>
> , "Alex Harui" <aharui@> wrote:
> >
> > capture phase listeners cannot assume the type since child objects may
> > be conversing with the same event type .
> > 
> > ________________________________
> > 
> > From: [email protected] <mailto:flexcoders%40yahoogroups.com>
> [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com>
> ] On
> > Behalf Of ben.clinkinbeard
> > Sent: Monday, August 27, 2007 6:26 AM
> > To: [email protected] <mailto:flexcoders%40yahoogroups.com> 
> > Subject: [flexcoders] Re: Event collision- is this a bug or expected
> > behavior?
> > 
> > 
> > 
> > bump
> > 
> > --- In [email protected]
> <mailto:flexcoders%40yahoogroups.com>
> <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> 
> > <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