This content has been marked as final. Show 5 replies
This is a good question. I typically use long descriptive strings for my events and have not yet really worried about this. But I am about ready to go to the next level.
I see that the framework, and many other professioonal grade components, use what looks like an "ENUM" of sorts, so instead of "myEvent", you specify the type like MyClass.MYEVENT. I suspect that this make name collisions very unlikely
I do not yet know how to set this up in a component (haven't looked yet!) maybe someone here can give us a head start.
I'm not sure if this is what you're talking about or not... But if I call
addEventListener(MouseEvent.CLICK, handler1); OR
MouseEvent.CLICK and ListEvent.CHANGE are just string constants defined in their respective class... So the value of MouseEvent.CLICK is just "click" (in documentation)... This basically just makes it easier to tell the addEventListener what type to listen for, instead of having to remember the exact string that is used... But this doesn't eliminate the problem, because even if you use a string constant, it could have a value that is already "taken"...
Or did I misunderstand what you were saying...?
You may be correct. Perhaps then this just allows for complex strings as the event names?
I really do not know.
"ntsiii" <email@example.com> wrote in message
> This is a good question. I typically use long descriptive strings for my
> events and have not yet really worried about this. But I am about ready
> to go
> to the next level.
> I see that the framework, and many other professioonal grade components,
> what looks like an "ENUM" of sorts, so instead of "myEvent", you specify
> type like MyClass.MYEVENT. I suspect that this make name collisions very
No, it just helps avoid typos.
"istrasci" <firstname.lastname@example.org> wrote in message
> As I'm finally getting the hang of how to use custom events and custom
> classes, I realized that there might be naming conflicts... For example,
> class defines a custom event
> [Event(name="myEvent", type="flash.events.Event")]
> If I am using one/multiple third-party components in my application,
> no guarantee that they have not also defined an event of the same name &
> type... If the third-party code includes sizable/long files, I don't want
> have to go scraping through to make sure they don't have any of the same
> names... Or even if my own project has many files, I may have duplicated
> name I already used elsewhere... I realize that the chance of the name
> the same is small, but with something that follows a convention (like
> "myEvent"), it could produce a conflict -- more likely within your own
> So how does Flex deal with conflicts??? Compiler warnings??? Do they
> them to go through and force the developer to deal with them? Just
Most of the time it doesn't matter, because you're listening specifically to
a component, and you know what events that component is going to send you.
In cases where you get a conflict, it's because you're listening for
bubbling events, and it's possible that multiple components could be
bubbling events with the same name. But then, we already have ways to
handle that (think about what you do if you're listening for a click event
on a parent container that contains multiple child containers--how do you
distinguish if it is the parent or which of the children it is).
Sometimes, you could run into a problem if you had, for instance a custom
MyClickEvent with a type of "click", because if you type the argument as
MyClickEvent and the argument that the listener gets is a normal click
event, you will get a runtime error when it tries to cast the MouseEvent to
a MyClickEvent on its way into the handler. To handle this, you should just
type the argument as Event and then use the "as" keyword to cast to your own
event type and handle the vent if your variable that contains the cast event
is not null.
If you're producing components for "public consumption", you should probably
try to give them a long string as Tracy suggested, because the longer the
string is, they less likely there are to be collisions. So "clickOnAFoo" is
much less likely to cause a conflict than "click".