Организация мышиных событий в приложении
 

Чувство, что я уже это спрашивал, но возможно оно из-за того, что собирался:)
Раньше думал, что со временем долно быть легче, но сейчас вообще мысли взрываются. В голове всё смешалось и я опять на пороге "начала". Вроде кажется, что всё очень просто, но есть у меня кнопка, она при over, out, down, up меняется, анимация на собственном mc, как я подсмотрел у Dukobpa3'а и в у Starling, это к вопросу не относится. Так же есть всплывающая подсказка, а то она ещё может быть и анимированная. Курсоры ещё.. меняются.. И вариантов ой как много, но хочется более правильный и тот, который себя уже зарекомендовал. Первое что приходит в голову, Observer, но помнится, что до недавнего времени при вопросе - откат действий пользователя на шаг назад, в голове бы всплыл шаблон, не помню название, вроде команда, но оказалось что ещё есть и Memento, который мне понравился. Что посоветуете?

Помогите понять ваш вопрос. Для какой задачи вы ищите подходящий шаблон, если всё сказанное
?

Неправильно наверное высказался... Не относится то, что я подсмотрел организацию собственных MC.
А упомянул я об этом, наверное, чтобы Вам было понятней, что класс mc не будет ДО.
Но суть вот в чём - в моей голове нет понятия кнопки и прочего, есть только область реагирующая на мышь.
И есть много классов, которые ожидают уведомление об событии. Но как организовать все это? Смотря менеджер курсоров, я обратил внимание, что автор сделал класс, куда передавал объекты и там их подписывал, но ещё он упомянул, что сам именно таким вариантом не пользуется и я принил эти слова именно связанных с этим классом. Ведь получится, что менеджер курсоров получает ссылки на кнопку и подписывает её, менеджер подсказок проделывает тоже самое. И там возможно ещё кому-то понадобится узнавать об этих событиях. Как лучше сделать, где подсмотреть?

Добавлено через 26 минут
Если в менеджеры раздавать объекты и там их подписывать, то получится обсервер. И если думать на таком примитивном уровне, то подписать один объект на одни и теже события в нескольких местах, кажется логичнее, чем объект, который хранит в себе ссылки на классы, которым нужны уведомления. Можно делать и утилсы под себя и просто передавать объект в менеджеры, которые будут ждать подготовленный для них калбэк. Но это не правильно, так как я не хочу писать свой фреймворк, а стремлюсь к максимальным возможностям без лишней тяжести.

Добавлено через 30 минут
Мне нужен толчок в этой теме, а то я со всеми шаблонами уже так перестарался, что они уже все смешались. Просто совет.. Описания минимальные..

Я наверно вряд ли вам подскажу что-то по делу. Но попробуйте не упираться в какой либо конкретный из шаблонов. Попробуйте разные подходы и посмотрите лично для себя, как вам удобнее будет. Верный вариант, приходит не сразу, а именно после разных попыток его реализации. Возможно вы и сами придумаете какой-то новый шаблон (или более удобный), под вашу задачу.
Очень важно искать путь самому. Я совершенно не против того, что вы ищете ответ здесь. Просто хочу напомнить и о том, что возможно Вы сами можете найти все ответы.

samana Спасибо за совет! Но самому ужасно сложно и иногда хочется чтоб рассказали. Пойду дальше экспериментировать.

Добавлено через 15 часов 47 минут
Ещё вот что мешает думать - одно приложение, один EnterFrame. Много раз слышал эти слова и сам думал, что так и должно. Но чем MOUSE_MOVE отличается, не чем, а значит и про это событие можно сказать, что оно должно быть одно на всё приложение. А дальше начинаешь рассуждать, как имея один EF или MM оповещать множество подписчиков и на ум приходит только одно, создать класс, в который будешь добавлять в массив все объекты и по событию все оповещать. И того добавить\удалить из массива, цикл, в котором будешь оповещать всех нуждающихся, какой-то класс. И получается, что все это, попытка создать на основе EventDispatcher ещё один, который только замедлит выполнение. Но тогда встаёт вопрос, почему говорят - одно приложение, один EnterFrame? Ведь подписать один объект на какое-то событие в разных местах или много энтерфраймов будет правильнее с точки зрения реализации самого языка. Или я не прав?

Было бы интересно услышать хотя бы ОДНО, в чем они НЕ отличаются.
Ентерфрейм это многоадресное автоматическое гарантированное событие.
Маусмув это селективное пользовательское интерактивное событие.

Они оба не cancellable :)

Akopalipsis, получая ентерфрейм в единственном месте, Вам не надо тратить ресурсы на вычисление, от кого Вы его получили. Вы просто "сами" решаете, как его раздать, кто должен теперь измениться, и как.
Технически, Вы конечно можете так же подписать на маусмув только стейдж. Но дальше начнется шершеляфам с неизбежными ошибками и стостроковыми свитчами. Оно кому надо?
В первом случае вам нужно решить, кому сказать. А во втором — понять, от кого услышали. Вам все еще кажется, что это одно и то же?

Wolsh Спасибо! Мне вот ещё что хочется узнать.. Есть кнопка, она при over\out меняется, так же есть менеджер курсоров, который при over должен ставить особенный курсор. Но менеджер может узнать о over, только если ему передать кнопку, которую он подпишет. Получается, что кнопка подписана на over, в самой себе или ещё как-то, это уже от реализации самой кнопки зависит, но ещё она же подписана повторно в менеджере. Такой подход нормальный? Когда об этом думаю я, то вижу лишь один минус, кто-то должен знать, что кнопку держит слушатель, который не позволит её удалить.
Но если без этого, то миллион флагов или ещё что-то, куда более хуже.. Как мне мысли собрать в кучу?)

КАК слушатель не позволит удалить кнопку???

Добавлено через 31 минуту
Имеется в виду менеджер, которому дали ссылку на кнопку?
Так, простите конечно, но разве Вы не должны сказать менеджеру, что одного из его подопечных убили? Вы, то есть, считаете нормальным удалять все что ни попадя, не предупреждая никого, кто еще пользуется этими же экземплярами? Вам срочно нужно написать проект с более чем двумя классами.