A word of caution, someone told me the code in this post might not be a good example of best practices, because the event was made fully [Bindable], defaulted to bubbling, and the constructor does not allow control over bubbling. But hopefully you will find it useful to gain a better understanding of some aspects of custom events.
I'm still new to custom events, but if anyone can shed light on improvements to my cookbook post, it would be great.
I changed the code so the custom event class is no longer [Bindable], as I guess it doesn't really need to be. I also changed it so the listener listens during capture phase, made the event not bubble by default, and added support allowing you to make the event bubble if you need it to.
If there is any way this code could still be improved, please let me know.
After perusing the SDK classes, I realize that all arguments from the superclass should go first in constructor arguments.
Also, although we are listening in capture phase, both the bubble and capture phase have the problem of requiring unique event names. This is why the application frameworks recommend singletons like model singletons so you can listen directly to them instead of basically broadcasting to everyone (bubbling) or listening to everyone (capture).
That would be a bit more complex, and I am trying to keep this simple, but another good point to keep in mind.