Всплывающая подсказка

[caseyryan]

Сообщение от undefined

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

stage всегда один. Хоть десять флешек загрузи)) Ничего поверх разных оверлеев выскакивать не будет, если все сделано правильно.
У меня вообще система работает так (тут немного урезанный вариант):
1) Все объекты, у которых может быть подсказка применяют интерфейс ITooltip, в котором есть геттер / сеттер для поля hintText и localToGlobal(point:Point):Point
вот так:

public interface ITooltip {
   function set hintText(value:String):void;
   function get hintText():String;
   function localToGlobal(point:Point):Point;
}

2) Класс Tooltip инициализируется с передачей ему stage, на которую он сразу вешает два слушателя
ROLL_OVER, ROLL_OUT
3) Дальше в обработчике ROLL_OVER проверяет что это за объект

private function onRollOver(e:MouseEvent):void {
     if (e.target is ITooltip) {
           showTooltip(e.target as ITooltip); // показываем подсказку
     }
}
private function showTooltip(tooltip:ITooltip):void {
      _currentHint = getHintFromPool(); // постоянно юзает один и тот же лейбл для подсказок. Больше не требуется
     _currentHint .setText(tooltip.hintText);
      var position:Point = tooltip.localToGlobal(new Point());
      _currentHint x = position.x;
      _currentHint .y = position.y; 
     // тут еще можно рассчитать положение со смещением, чтобы за границами экрана не вылезал, если близко к краю
      stage.addChild(_currentHint );
}

4) В обработчике rollOut убирает подсказку

private function onRollOut(e:MouseEvent):void {
    if (_currentHint) {
       _currentHint.remove(); // там подсказка еще подписана на событие removedFromStage, чтобы возвращаться в пул
       _currentHint = null;
    }
}

5) Если rollOut не было в течение заданного времени, то она сама удалится
6) Профит

Не знаю как там у тебя что показывается поверх оверлеев. С этой системой такое в принципе невозможно.
Когда я ещё писал на флеше, эта либа у меня успешно кочевала из проекта в проект и никогда не глючила

п.с.

Разве статический класс не может реализовать дополнительную логику

В AS3 нет статических классов, есть только статические свойства и методы. Это так, к сведению

[undefined]

stage всегда один

Это не значит что можно пихать на него все подряд.

Класс Tooltip инициализируется с передачей ему stage, на которую он сразу вешает два слушателя

Смотри владелец контейнера решил нарисовать поверх флэшки попап.Положим что у попапа нет бэкграунда,который перехватывает все маус ивенты.Твоя флэшка продолжет ловить ROLL_OVER, ROLL_OUT и лепить хинты поверх всего.

если все сделано правильно.

Правильно - это как раз когда все принадлежащие флэшке DO лежат в рамках одного контейнера, с которым можно делать все что угодно: перекрыть/сжать/повернуть/выставить альфу.А твой подход самый настоящий костыль.

Когда я ещё писал на флеше, эта либа у меня успешно кочевала из проекта в проект и никогда не глючила

Единственное о чем это говорит - ты не натыкался на кейсы где бы это не работало.

[caseyryan]

Это не значит что можно пихать на него все подряд.

Л - Логика Зачем аргументы? Нельзя и всё тут)

Смотри владелец контейнера решил нарисовать поверх флэшки попап.Положим что у попапа нет бэкграунда,который перехватывает все маус ивенты.Твоя флэшка продолжет ловить ROLL_OVER, ROLL_OUT и лепить хинты поверх всего.

А если бы у бабушки был ..., она была бы дедушкой) Давай без если бы да кабы.
А то можно сказать, а если бы владелец контейнера удалил твой контейнер, то твоя игра вообще не работала бы.

Правильно - это как раз когда все принадлежащие флэшке DO лежат в рамках одного контейнера, с которым можно делать все что угодно: перекрыть/сжать/повернуть/выставить альфу.А твой подход самый настоящий костыль.

Ты это "правильно" сам придумал?
Я бы сказал так, приложение, в котором что-то там со стороны загружается и добавляется, без учета логики родительского приложения - это и есть костыль.

[undefined]

Л - Логика Зачем аргументы? Нельзя и всё тут)

Я привел конкретный кейс когда твоя схема не сработает.

А если бы у бабушки был ..., она была бы дедушкой) Давай без если бы да кабы.

Т.е. ставим контейнеру ультиматум - не вздумай ничего рисовать поверх флэшки?Я уж молчу что появление хинта может быть и без mouseEvent'а(по таймеру например)

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

Добавлено через 16 минут

Я бы сказал так, приложение, в котором что-то там со стороны загружается и добавляется, без учета логики родительского приложения - это и есть костыль.

Ну так ты как раз и предлагаешь не учитывать что родитель имеет полное право что-то отрисовать поверх флэшки.

Добавлено через 26 минут
более того,это еще и вынуждает родителя тоже гадить на stage т.к. это единственный способ перекрыть всё)

[caseyryan]

Я привел конкретный кейс когда твоя схема не сработает.

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

Я уж молчу что появление хинта может быть и без mouseEvent'а(по таймеру например)

Не может. Этот хинт появляется точно так же как в любой десктопной операционке. А именно при поднесении к нему курсора. И никак иначе.

Ну так ты как раз и предлагаешь не учитывать что родитель имеет полное право что-то отрисовать поверх флэшки.

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

более того,это еще и вынуждает родителя тоже гадить на stage т.к. это единственный способ перекрыть всё)

В моих приложениях не вынуждает. Как у тебя, не знаю

[undefined]

Кость, смотри есть 2 случая:
1)Работает всегда с оговорками
2)Работает всегда без оговорок.
Давай на этом закончим пусть тс сам выбирает.
При грамотной архитектуре переделать (1) в (2) можно в одну строку.Я в свое время это сделал заменой этого

app.startApp(stage);

на это

app.startApp(root);

В моих приложениях не вынуждает. Как у тебя, не знаю

у меня тоже не вынуждает т.к. все сидит в рамках одного DOC

[caseyryan]

Сообщение от undefined

Кость, смотри есть 2 случая:
1)Работает всегда с оговорками
2)Работает всегда без оговорок.

Смотри, что мешает добавить в класс тултипа сеттер paused, к примеру?
Ставим его на паузу, при необходимости, и тултип не появляется пока не снимем с паузы.
Если допустить, что есть какая-то родительская флешка, в которой этот тултип может что-то там перекрывать, то она может просто временно отключить тултип. В любом случае и при твоем варианте у нее должен быть механизм отключения их, пусть даже блокировкой контейнера с тултипами, но должен быть. Так что код постановки на паузу этой системы легко можно реализовать.

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

[undefined]

Смотри, что мешает добавить в класс тултипа сеттер paused, к примеру?
Ставим его на паузу, при необходимости, и тултип не появляется пока не снимем с паузы.

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

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

Не нужен никакой механизм т.к. тултипы никогда не вылезут из главного контейнера и никому мешать не будут.

[Appleman]

Сообщение от Wolsh

Никак. Им не надо. Главный Вью сам запихает кого надо куда надо, или даст ссылки на нужные слои их Менеджерам.

У меня сейчас такая конструкция вышла. Поскольку создаваемая мини-игра будет в перспективе частью более крупной, то я решил сразу разделить View. Создал MainView, которая просто добавляется в главные DOC и ничего пока не делает. А затем контроллер мини-игры создаёт BattleView, помещает его в MainView и говорит "банкуй!". Там у меня уже начинается разметка экрана под мини-игру, создание компонентов и т.п. Поэтому я и спрашиваю, что не грех бы ей получить эти слои, чтобы ориентироваться, чего куда выставлять. Или я всё изначально неправильно спланировал?

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

Это правда. Но что меняется в случае, если класс не "статический", а "обычный" с экземплярами? Какой от этого выигрыш?

Добавлено через 6 минут

Сообщение от caseyryan

В AS3 нет статических классов, есть только статические свойства и методы. Это так, к сведению

Спасибо за пример. На счёт "статических" классов специально брал в кавычки. Понятно же о чём речь.

[Wolsh]

если класс не "статический", а "обычный" с экземплярами? Какой от этого выигрыш?

Нууу... (я иногда теряюсь от твоих вопросов об очевидном) Экземпляры надо когда-то и где-то (кем-то) создавать, где-то хранить, и протаскивать ссылку до самого последнего элементика, нуждающегося в развернутом описании. То есть, для такого элемента в момент когда он хочет показать хинт (а это не только при наезде мышкой, не слушай Кейси — он видимо никогда не сталкивался с режимом обучения) совершенно не очевидно, какой именно экземпляр менеджера обслуживает его район, не очевидно, что он УЖЕ создан и как к нему обратиться с заданием. Мне вот совершенно непонятно, что за экземпляры и зачем они нужны; что за персональные данные они должны хранить и по-разному обрабатывать (а если нет индивидуальности, то зачем экземпляры). Мне видится, что они только добавят хаоса вместо порядка — "у семи нянек дитя без глазу" — так еще и за ними самими кто-то следить должен, создавать, расшаривать, укладывать спать.