Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 02.10.2013, 23:38
KumoKairo вне форума Посмотреть профиль Отправить личное сообщение для KumoKairo Найти все сообщения от KumoKairo
  № 11  
Ответить с цитированием
KumoKairo
 
Аватар для KumoKairo

Регистрация: Jan 2013
Сообщений: 550
Записей в блоге: 1
Akopalipsis, поймите, что "вешать слушатель на стейдж" - это настолько обширное понятие, что нельзя просто взять и сказать - "вешать слушатель на стейдж - хорошо".
Я поэтому и уточнил, мол, клик по стейджу слушать будем?)
В случае с клавиатурой просто нет другого варианта - это уже совсем другой слушатель.

Фраза "вешать слушатель на стейдж - хорошо" в корне не верна. Даже если отойти с примером про кнопку - если у вас есть лоадер или сокет, или еще что-то, выдающее отчет о проделанной работе - вы слушатель тоже на стейдж добавите?)

Да и с кнопками, блин, этож вообще. Если делать несколько слушателей на MouseEvent.CLICK на стейдж то будут вызываться все слушатели разом, хотя вам для каждой конкретной кнопки чаще всего нужен будет свой колбэк. Если вешать слушатель клика на стейдж, то в каждом из них (из слушателей) придется проверять - а тот ли объект был нажат? Чтобы не возникло случая как с кнопкой закрытия приложения)
Да и потом - зачем какой-то части программы знать, что где-то там, далеко, на другом логическом экране, была нажата какая-то кнопка?
В общем пересмотрите свои взгляды насчет "вешать слушатель на стейдж - хорошо", подумайте несколько шире.

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

Старый 03.10.2013, 00:06
Akopalipsis вне форума Посмотреть профиль Найти все сообщения от Akopalipsis
  № 12  
Ответить с цитированием
Akopalipsis
Banned
[+4 24.02.14]
[+4 07.11.13]
[+ 13.03.14]

Регистрация: Mar 2013
Сообщений: 1,864
KumoKairo Спасибо за обьяснения и что Вы меня поправили - научили ещё чему то! Слова "хорошо" я исправил, чтобы кто то не прочёл.
Но тогда и приравнивать события и добавления обьектов тоже не надо! Вы же могли меня убедить в том, что это одно и тоже. И в следующий раз я бы при таком совете начал бы говорить, что не надо мне ерунду советовать.)

Старый 03.10.2013, 00:39
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 13  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Цитата:
А почему добавлять объекты на стейдж плохо?
http://flasher.ru/forum/showpost.php...82&postcount=8
http://flasher.ru/forum/showpost.php...60&postcount=7
http://flasher.ru/forum/showpost.php...4&postcount=11
http://flasher.ru/forum/showpost.php...2&postcount=22
__________________
Reality.getBounds(this);

Старый 03.10.2013, 09:13
KumoKairo вне форума Посмотреть профиль Отправить личное сообщение для KumoKairo Найти все сообщения от KumoKairo
  № 14  
Ответить с цитированием
KumoKairo
 
Аватар для KumoKairo

Регистрация: Jan 2013
Сообщений: 550
Записей в блоге: 1
Цитата:
На самом деле вешать слушателя на стейдж - это хорошо ЭТО ПЛОХО!!!!,
Зря я все расписывал насчет слушателей похоже..

Это не хорошо и не плохо, это по-другому.

Старый 03.10.2013, 09:36
Fogflasher вне форума Посмотреть профиль Отправить личное сообщение для Fogflasher Найти все сообщения от Fogflasher
  № 15  
Ответить с цитированием
Fogflasher

Регистрация: Mar 2013
Сообщений: 290
Цитата:
Сообщение от Akopalipsis Посмотреть сообщение
я точно знаю, что добавлять на стейдж обьекты - нельзя!
Хм, а по Муку вроде как можно, вот например:

For example, the following code modifies the App class from Example 20-5 so that the Sprite object
and its child Shape object are added directly to the Stage instance. Because the Sprite
and Shape objects are not descendants of a .swf file’s main class instance, their root
variables refer to the Stage instance.


Код AS3:
package {
  import flash.display.*;
  import flash.geom.*;
  public class App extends Sprite {
    public function App ( ) {
      var rect:Shape = new Shape( );
      rect.graphics.lineStyle(1);
      rect.graphics.beginFill(0x0000FF, 1);
      rect.graphics.drawRect(0, 0, 75, 50);
      var sprite:Sprite = new Sprite( );
      sprite.addChild(rect);
      // Add child to Stage instance, not this App instance
      stage.addChild(sprite);
      trace(rect.root);    // Displays: [object Stage]
      trace(sprite.root);  // Displays: [object Stage]
    }
  }
}
Ну, то есть, чисто технически можно.
Но идеологически, как мы теперь знаем, это есть зло - согласно заповедям от Wolsh, например : )

Старый 03.10.2013, 10:48
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 16  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
Хм, а по Муку вроде как можно, вот например:
Ну, как бы, тут никто и не ставил под сомнение техническую возможность. Технически можно вообще неимоверную кашу нагородить в коде.

Вообще, вот это верно
Цитата:
Это не хорошо и не плохо, это по-другому.
Допустим есть менеджер подсказок, которые показываются при поднесении курсора к объекту , например, применяющему интерфейс IHintable. В этом случае ROLL_OVER / ROLL_OUT разумнее всего повесить именно на stage, так как необходим доступ ко всем таким объектам, независимо от их расположения. Можно конечно цепануть и к документ классу, но лично я разницы не вижу, никаких плюсов в этом не будет

Старый 03.10.2013, 11:15
KumoKairo вне форума Посмотреть профиль Отправить личное сообщение для KumoKairo Найти все сообщения от KumoKairo
  № 17  
Ответить с цитированием
KumoKairo
 
Аватар для KumoKairo

Регистрация: Jan 2013
Сообщений: 550
Записей в блоге: 1
Цитата:
В этом случае ROLL_OVER / ROLL_OUT разумнее всего повесить именно на stage, так как необходим доступ ко всем таким объектам, независимо от их расположения. Можно конечно цепануть и к документ классу, но лично я разницы не вижу, никаких плюсов в этом не будет
Я специально написал что подобные случаи рассматриваются в личном порядке. Вопрос изначально был про клик по стейджу и то, что это "хорошо".

Старый 03.10.2013, 11:39
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 18  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
Я специально написал что подобные случаи рассматриваются в личном порядке. Вопрос изначально был про клик по стейджу и то, что это "хорошо".
Ну я, в общем-то, и не спорил ни с чем

Старый 04.10.2013, 01:41
in4core вне форума Посмотреть профиль Отправить личное сообщение для in4core Найти все сообщения от in4core
  № 19  
Ответить с цитированием
in4core
[+4 06.05.14]
 
Аватар для in4core

Регистрация: Mar 2009
Сообщений: 4,219
Записей в блоге: 14
Цитата:
Плохо в минимальном понимании инкапсуляцией
Обычно так работают новички, когда Main класс едиснтвенный в программе, тогда и на стейдж не стыдно
__________________
Марк Tween

Создать новую тему Ответ Часовой пояс GMT +4, время: 13:23.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 13:23.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.