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

[Appleman]

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

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

Статический класс для подсказок хорош тем, что предоставляет один ларек для обращений, или точку входа, или как там. Правда, всем непонятным элементам придется его импортить, чтоб зарегистрироваться, но если их не катастрофически много, то почему бы и нет (а если много, то явно интерфейс требует пересмотра — игрок не должен сидеть и в задумчивости наводить мыша на каждый объект на экране, вытаясь понять что это с помощью подсказок). Если в хинте (тултипе, сорри) раскрывается дополнительная информация (не ЧТО, а ПОЧЕМУ например), то другое дело.. Но тогда надо сначала продумать механику — будет ли элемент сообщать Менеджеру подсказок только текст подсказки, или будет передавать готовый ДисплейОбжект с картинками, шкалами и графиками, который соберет сам.

Дальше я спросил, а чем в случае раскрытия "ПОЧЕМУ" нам не подойдёт всё тот же "статический" класс и что мешает добавить туда необходимую логику, на что ты ответил:

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

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

И вот в ответ на это я и спросил, а в чём, собственно, выигрыш в отказе от "статического" класса. Я понял, что в качестве альтернативы на описанный случай ты предлагаешь использовать "обычный" класс с экземплярами. Я об этом и спросил, в чём его преимущество.

И ещё просьба на счёт вью пояснить - это мой первый вопрос был из предыдущего сообщения. Я его ещё короче сформулирую. Правильно ли создавать отдельные "главные" вью или должен быть один главный "командир", который просто в зависимости от текущей ситуации будет выводить разные дочерние компоненты?

[undefined]

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

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

[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, к примеру?
Ставим его на паузу, при необходимости, и тултип не появляется пока не снимем с паузы.

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

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

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