If you want to, but it'll just get deferred. Some event types like "focusIn" probably shouldn't be re-used since they are defined as bubbling events. Same would be true for mouseDown and that would cause lots of extra work on developers for no benefit.
________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of ben.clinkinbeard Sent: Wednesday, August 29, 2007 1:56 PM To: [email protected] Subject: [flexcoders] Re: Event collision- is this a bug or expected behavior? Hi Alex, It looks like somebody didn't follow your recommendations when writing FocusManager :) All of the focus related handlers have signatures that look like this private function focusInHandler(event:FocusEvent):void, causing a coercion error if a developer defines an event with a value that collides with one of FocusEvent's constants. Is this something worth filing a bug/enhancement for? Thanks, Ben --- In [email protected] <mailto:flexcoders%40yahoogroups.com> , "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:flexcoders%40yahoogroups.com> [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> ] On > Behalf Of ben.clinkinbeard > Sent: Monday, August 27, 2007 11:35 AM > To: [email protected] <mailto:flexcoders%40yahoogroups.com> > 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> <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:flexcoders%40yahoogroups.com> > [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> <mailto:flexcoders%40yahoogroups.com> > ] On > > Behalf Of ben.clinkinbeard > > Sent: Monday, August 27, 2007 6:26 AM > > To: [email protected] <mailto:flexcoders%40yahoogroups.com> <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> > <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> > > > <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 > > > > > >
