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

[Appleman]

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

[Godwarlock]

Appleman добавь контейнер выше остальных и туда добавляй подсказку. Я бы вообще вынес подсказку в отдельный класс, ибо нечего ей делать в классе иконки

[caseyryan]

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

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

Обычно такие подсказки (которые называются туллтипы, англ. Tooltip) Делаются в отдельном контроллере, и вызываются через статические методы. А добавлять подсказку можно прямо на stage

[Appleman]

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

Appleman добавь контейнер выше остальных и туда добавляй подсказку. Я бы вообще вынес подсказку в отдельный класс, ибо нечего ей делать в классе иконки

Ну почему же нечего? Мне показалось, что очень даже удобно получилось намутить класс, подбирающий по запросу иконки: картинку, текст всплывающей подсказки на нужном языке. Хотя да, исходные объекты - из разных классов. Можно подробнее на счёт отдельного контейнера? Если я цепляю к иконке, то по определению ограничен её контейнером.

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

Обычно такие подсказки (которые называются туллтипы, англ. Tooltip) Делаются в отдельном контроллере, и вызываются через статические методы. А добавлять подсказку можно прямо на stage

Да, имеются в виду именно они, спасибо за правильный термин. Можно подробнее про отдельный контроллер и статические методы? Как это должно работать? У меня тоже была мысль непосредственно на stage добавлять. Но необходимость дополнительного контроллера даже близко не понимаю пока.

[undefined]

а как же мантра что stage приложению не принадлежит и лежать там должен только главный контейнер - root?

[Wolsh]

Эта страсть неистребима, засорять стейдж разными выкидышами. Вот вроде ничего не мешает иметь специальный слой поверх всего прямо в главном Вью, никаких проблем СРАЗУ разделить все отображение по слоям, чтобы HUD был всегда поверх мира, слой для главных Меню — поверх HUDа, а подсказки поверх всего (кроме, может быть, слоя с экраном для видеозаставок). Но нет, проще выплюнуть что-нибудь на стейдж.

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

А в остальном обычно делают так: элемент, который хочет рассказа о себе, регистрируется у Менеджера через статик метод register(), в который передает ссылку на себя и текст/готовый хинт, и может быть политику по размещению хинта (типа "сверху по центру, не двигать за мышкой"). Менеджер оформляет подписку на маусОвер/маусМув/маусАут для этого объекта и сохраняет текст/ДО и политику например в Dictionary. Когда с объектом случится запланированный наезд мышой, Менеджер закидывает его хинт в специальный высоколежащий слой для подсказок, а когда надо — вынимает его оттуда.

Менеджер также должен предоставить метод unregister(), который объект вызовет перед смертью в своем методе destroy().

[caseyryan]

Вот вроде ничего не мешает иметь специальный слой поверх всего прямо в главном Вью, никаких проблем СРАЗУ разделить все отображение по слоям, чтобы HUD был всегда поверх мира, слой для главных Меню — поверх HUDа, а подсказки поверх всего (кроме, может быть, слоя с экраном для видеозаставок). Но нет, проще выплюнуть что-нибудь на стейдж.

Слои слоями, а подсказки можно легко кидать на stage. Ничего плохого в этом нет, если у подсказки есть встроенное время жизни. У меня это обычно в районе 3 секунд было. После чего она сама удаляется снова в пул. Полностью автономная система. А вот такие высказывания вроде "ни в коем случае нельзя ничего кроме root добавлять на stage" мне напоминают паранойю) Если бы разработчики языка не хотели, чтобы что-то можно было добавлять на stage, то к ней просто не было бы доступа

[Appleman]

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

Эта страсть неистребима, засорять стейдж разными выкидышами. Вот вроде ничего не мешает иметь специальный слой поверх всего прямо в главном Вью, никаких проблем СРАЗУ разделить все отображение по слоям, чтобы HUD был всегда поверх мира, слой для главных Меню — поверх HUDа, а подсказки поверх всего (кроме, может быть, слоя с экраном для видеозаставок). Но нет, проще выплюнуть что-нибудь на стейдж.

Спокойно! Никто никуда ничего пока не выкидывает. Я потому и спрашиваю, что почуял, шняга какая-то выходит. Поясни, плиз, как размечать слои в главном вью? И как дочерние вью получат доступ к этим слоям?

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

Почему сразу пересматривать? Мне кажется, что это хорошая привычка - добавлять тултипы ко всем графическим элементам интерфейса для удобства игрока. В конце концов, там где одному видится сердце, другой увидит жопу. Дело такое.

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

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

А что меняется, если раскрывается? Разве статический класс не может реализовать дополнительную логику, связанную с ПОЧЕМУ? Например, текст тултипа иконки зависит от значения какого-то свойства. Почему нельзя передать это значение (или экземпляр класса, содержащий это значение) прямо в статический метод, и всё сделать в нём?

А в остальном обычно делают так: элемент, который хочет рассказа о себе, регистрируется у Менеджера через статик метод register(), в который передает ссылку на себя и текст/готовый хинт, и может быть политику по размещению хинта (типа "сверху по центру, не двигать за мышкой"). Менеджер оформляет подписку на маусОвер/маусМув/маусАут для этого объекта и сохраняет текст/ДО и политику например в Dictionary. Когда с объектом случится запланированный наезд мышой, Менеджер закидывает его хинт в специальный высоколежащий слой для подсказок, а когда надо — вынимает его оттуда.

Менеджер также должен предоставить метод unregister(), который объект вызовет перед смертью в своем методе destroy().

Я правильно уловил, что главная суть и предназначение этой регистрации - это добавление слушателя событий экранного объекта? Скажи, пожалуйста, если использовать Dictionary, то что уместно использовать в нём в качестве ключей? Сами экранные объекты: иконки, кнопки, шкалы и т.п.? А если они также "собираются на лету" в рантайме?

[Wolsh]

Поясни, плиз, как размечать слои в главном вью?

создать переменные типа Спрайт, наделать экземпляров класса Спрайт, добавить их в отображение в нужном порядке и больше этот порядок не менять.

И как дочерние вью получат доступ к этим слоям?

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

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

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

главная суть и предназначение этой регистрации - это добавление слушателя событий

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

А если они также "собираются на лету" в рантайме?

Эмм... ну так ВСЕ собираются на лету в рантайме.. Должен помереть — сделай анрегистр() и все, свободен удаляться.. Или я чего то не понял в вопросе? Может, ты имеешь ввиду что регистрация должна происходить при создании класса Хинт? Так нет же — при создании объектов. Сам объект, или тот кто его создает, проводит регистрацию объекта в Хинте.

[undefined]

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

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