как устроен Listener?
 

Интересно как работает Listener? это какая-то функция, висящая onEnterFrame или что-то по-хитрее?

Хых, я выбираю вариант б)

Вас интересует дамп участка кода в памяти, где расположен Listener, изложенный на языке ассемблера?:)
Ну а вообще Listener это объект призваный получать уведомление о наступлении какого-либо события другого объекта. Если Вы знакомы с концепцией сообщений Windows, то я думаю технология прослушивания событий во Флеше будет Вам понятна.

Listener — это метафизическое понятие, вбитое хелпом в голову начинающим флешерам. Listener — это такой обыкновенный объект-помойка, у которого объявлены с определенным именем методы, которые вызываются тем объектом, который, собственно, «слушают». На деле этот Listener — мусор, бессмысленный объект. Последняя стадия заплывших мозгов — создавать такой объект, а потом вешать на него делегаты методов на this.

Привет!
Мне кажется автора топика скоре всего интересует сам механизм листенерства, то есть, его мучает сомнения по поводу загруженности процессорного времени. Для получения сообщения листенер должен опрашивать: "А не поменялось что-либо у вас? А не произошло ли событие какое-нибудь?"
То есть в итоге схожесть на так не любимый всеми EnterFrame, а может как раз и сам EnterFrame реализован в методах листенера! Расплодив листенеры возможно ли тормознуть программу? В ответах даны определения и оценка Listener.
Но, может я ошибаюсь и вы и __etc уже дали удовлетворительный ответ.

Привет Жень Шень! То что Вы зацитировали это всего лишь шутка и я никоим образом нехотел обидеть Вас и автора! Дело в том, что вопрос листенерства настолько обширен и щекотлив, что даже уходит своими корнями в латентные механизмы организации сообщений в Windows! И да простят меня великие WinAPI- программисты! Но поверхностно, не в даваясь в подробности алхимии Windows, а касаясь только части реализации концепции организации сообытий и их отлова во Флеш, можно и по дискутировать. Ведь это будет полезно не только нашему уважаемому автору, но и другим заинтересованным в данном вопросе участникам форума.

Если Вы еще не знакомы с концепцией сообщений Windows - в двух словах, есть конвейр, в который вталкиваются некие сообщения - какие-либо системные события (например клик левой кнопки мыши). Каждое сообщение ждет своей обработки в соотвествии с выстроевшейся очередью. Безусловно, излишество в наступивших сообщениях в ситеме сказывается на производительности всей системы. Эту гипотезу не трудно проверить, если создать какой-нибудь периодически выполняющийся код с таймером и замерять время выполнения кода в каждом цикле при , например, активном движении мыши и без него.

Вообще да, хотелось бы понять насколько сильно загружается система от повышения кол-вов Listener ?
то есть все события пользователя вталкиваются в такой конвеер и каждое событие проверяет - "будут ли его использовать"?

Привет!
Упаси Бог обижаться! Мне приятно читать ваши коменты и стиль вашего общения. Просто я так понял автора и, кстати, самому стал интересен механизм листенерства.
Добавлено.
Автор "узаконил" мою догадку.

Как-то я не понял, какое значение вы пытались придать слову "латентные"? =)

И да, во флеше сообщения устроены немного по другому.
Хотя последовательное выполнение кода никто не отрицает. Паралельные вычисления флешной виртуальной машине врятли грозят. Да и не нужны.

Чтобы узнать - как устроены сообщения и слушатели во флеше, погуглите по поводу AsBroadcaster и будет вам счастье. Например давняя статья потрошителя. Или еще много чего полезного.

__etc, можно в двух словах, как стоит делать? Например с событиями Key.

В абсолютном большинстве случаев простым addListener(this) вместо addListener(someObject).

Ааа, т.е. готовым объектом пользоваться вместо создания нового - например внутри класса этим объектом будет этот самый класс. Тогда и Делегат не нужен. Спасибо.

Прикольно:
Странно, что нельзя напрямую снимать события с генерирующего их объекта. Ведь что в данном случае происходит? Объект Stage генерирует событие 'onResize' при его наступлении. Далее просматривает массив _listeners в себе и рассылает всем объектам этого массива, что событие 'onResize' произошло. Т.е. объект Stage получает от самого себя самому себе сообщение 'onResize', после чего выполняется назначенный на это событие метод.

Ничего странного. Генерирующий объект не слушает сам себя по умолчанию. И это логично. Потому что слушать должны только те объекты, которых подписали на событие.

1 вопрос? а можно ли послать сообщение из обьекта1, в другой обьект2 чтобы листенер установленный на обект2, поймал посланное собщение ?

в програмирование под win, такое реально :) через sendMessage:)

Реально. 1-й объект должен быть вещателем (AsBroadcaster), ну а 2-й листенером и слушать определенное событие 1-го объекта.

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

Хочу уточнить Broadcaster - "широковещатель":), т.е. генератор событий, доступных для всех, но "отлавливают" эти самые события только слушатели.