Это... как бы вам сказать - фишка в том, что вы не можете отменить capture фазу, и ни про какие подписывания на события внутри класса речь не идет. Банальная ситуация - положили кнопку "Закрыть" на форму. Подписались на событие и смело думаем, что кнопка "Закрыть" всегда нашу форму и закроет. А тут откуда ни возьмись - вундеркинд типа MATE / Swiz - взял ваше событие от кнопки и тупо остановил до того, как оно пришло получателю, который форму должен был закрыть. Вы сидите, клацаете по кнопке - а она ничего не делает - комфортно? А предотвратить / предвидеть? - А не сможете, т.как вундеркинд подписавшийся после вас получит событие первым. И вообще, читайте про вред глобального доступа / глобальных переменных и всего такого - это одного поля ягода.

Родитель должен позаботиться о Ваших детях! Он должен сообщить непослушному ребёнку ссылку на кнут, чтобы тот прислушался к нему и больше не шалил)

Что то-типа метода attachDispatcher(dispatcher:IEventDispatcher):void;

Ну как бы всегда и закроет. А в чем подвох?

Не тестил стоп пропагейшн на капчур фазе ) Опять нет повода не выпить.

Там достаточно просто чтобы в хендлере была какая-нибудь ошибка пойманая в другом месте, и планы по захвату мира накроются медным тазом.

А я не понимаю вообще событийную модель. Произошел клик по кнопке - событие со stage понеслось вниз, до виновника торжества - это capture фаза. Если её поймать - то беда, можно виновнику не узнать, что он виновник. Ну хорошо, бабблинг фаза всплывает и вызывает обработчики и у всех тех, кого пометила capture фаза. А вторая фаза на кой?

Ну можно это представить так:
стейдж - единственный, кто регистрирует на события, т.е. все клики происходят на стейдже.
далее, стейдж идет по видимому дереву объектов и проверяет, а является ли объект интерактивным, а находится ли он в зоне клика.
вот это и будет фаза "захвата" события.
Когда у объекта не остается интерактивных детей удовлетворяющих условию положения мыши, при том, что этот объект является верхним с точки зрения Z-индекса, то он назначается целью события - это и будет фаза "цель".
Ну и дальше это событие опять раздается всем объектам-родителям и прародителям целевого объекта - это фаза "всплытия".
По идее, фазу захвата вообще-то лучше было бы спрятать, именно потому, что если этот процесс остановить, то целевой объект может не получить событие. Но тут опять же есть подводные камни - иногда хочется одним махом запретить получать мышиные события всем элементам, или, если не запретить, то остановить - ну те же модальные окна, например. Ну и тут же спорный вопрос, а на сколько приложение в праве решать что делать стейджу, т.е. а хорошо ли это, если какое-нибудь загруженое приложение сможет следить за логикой событий загрузившего приложения и т.п. Не знаю, я не думаю, что тут возможен однозначный ответ, но, мне кажется, что запрещать по умолчанию с возможностью разрешить, если потребуется был бы оптимальный вариант.

Да спасибо, это я понимаю. Мне не понятно, зачем фаза цель нужна.
Мы углубились, потом всплыли и всем рассказали...

Возможно чтобы не делать:
а вместо этого:
А вообще - не знаю, как-то не приходилось пользоваться :)

Что, прости? UPD: а, тьфу. Голова нарисовала скобки вот так:
и в голове каша случилась )

Да, та же ерунда - не приходилось сталкиваться поэтому и не знаю )

Я так понимаю, что EventPhase.TARGET может быть только у виновника события, все остальные получат EventPhase.BUBBLING, ну некоторые при желании ещё и capture фазу, верно?

Пример с текстовым полем, дитем спрайта. addEventListener'ом озадачиваем спрайт. Кликаем по текстовому полю. Вопрос. Произойдет ли в листенере спрайта, что ?

Добавлено через 11 минут
Олег, я подписываюсь (сторонним объектом) на capture phase, и в его хендлере генерю RTE. Правильно я понял?