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

[Tor4ok]

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

[Kamchatka]

Хых, я выбираю вариант б)
что-то по-хитрее

[Alex_beginner]

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

[etc]

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

[Жень Шень]

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

[Alex_beginner]

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

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

[Tor4ok]

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

[Жень Шень]

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

[crazyone]

латентные механизмы организации сообщений в Windows!

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

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

Чтобы узнать - как устроены сообщения и слушатели во флеше, погуглите по поводу AsBroadcaster и будет вам счастье. Например давняя статья (http://flash-ripper.com/articles/flash/2002_05_22_asbroadcaster.php) потрошителя. Или еще много чего полезного.

[Волгоградец]

Последняя стадия заплывших мозгов — создавать такой объект, а потом вешать на него делегаты методов на this.
__etc, можно в двух словах, как стоит делать? Например с событиями Key.

[etc]

__etc, можно в двух словах, как стоит делать? Например с событиями Key.
В абсолютном большинстве случаев простым addListener(this) вместо addListener(someObject).

[Волгоградец]

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

[chingachgoog]

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

Прикольно:

Stage.scaleMode="noScale"
Stage['onResize']=function(){
trace(this.width+"x"+this.height)
}
Stage.addListener(Stage)


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

[crazyone]

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

[darksranger]

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

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

[Волгоградец]

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

[chingachgoog]

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

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

[Alex_beginner]

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

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