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

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

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 06.11.2017, 02:19
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 61  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Wolsh Посмотреть сообщение
1) У тебя же эти Меню создаются и уничтожаются по пять штук в минуту, КАК контроллер должен на них подписываться? Вью будет говорить контроллеру событием "я тут новое меню забабахала, подписывайся, лайкай"?
Я контроллер подписал на событие от _view. Ведь он должен всегда быть готовым поймать выбор пользователя... Но если имя события совпадает (как и получилось при отправке события MenuEvent), но контроллер его тоже ловит. Всплыло? Чтобы не путать события от меню во вью с событием от вью в контроллер, я создал ещё одну константу типа события в классе MenuEvent: MENU_COMMAND.

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

Код AS3:
		private function showMenuHandler(event:Event) : void 
		{
			var options : Array = MinigameModel(event.target).menuOptions;
			var simpleMenu:SimpleMenu = new SimpleMenu(stage.width, stage.height - MAIN_TEXT_AREA_HEIGHT, options);
			this.addChild(simpleMenu);
			simpleMenu.addEventListener(MenuEvent.MENU_SELECT, menuSelectHandler);
		}
 
		private function menuSelectHandler (event: MenuEvent):void
		{
			dispatchEvent (new MenuEvent(MenuEvent.MENU_COMMAND, event.id));
			event.target.removeEventListener(MenuEvent.MENU_SELECT, menuSelectHandler);
			this.removeChild(event.target as SimpleMenu);	
		}


Последний раз редактировалось Appleman; 06.11.2017 в 16:59.
Старый 06.11.2017, 17:00
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 62  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Цитата:
Это нормально?
В целом неплохо. Единственное, и ты сам чувствуешь что это костыль — иметь два типа для по сути одного события.. И проблема тут немного в другом месте — лучше бы иметь события класса ViewEvent и диспатчить из Вью именно их. Тогда и контроллеру не нужно будет импортить в себя ("знать") класс событий, которые распространяются внутри Вью. Безжалостная инкапсуляция не позволит контроллеру иметь доступ к внутренностям Вью через event.target.
Второй момент касается безопасности некоторых операций. Например, надо буквально завести себе привычку перед removeChild() ВСЕГДА проверять, есть ли парент и есть ли чайлд. Общепринятая конструкция выглядит так:
Код AS3:
if (displayObject.parent == this) this.removeChild(displayObject);
Даже когда тебе кажется что ну никак не может возникнуть ситуация, что меню не дитя Вью, иногда случаются совершенно волшебные казусы, вызванные особой очередностью выполнения обработчиков и кода текущего фрейма.

Ну и совсем в порядке ворчания — если начал писать this. то пиши его везде. Одинокий, висящий в воздухе "dispatchEvent" смотрится каким-то робким и неуверенным в себе. К слову, олдскульные холиварщики подняли бы тебя на смех, убеждая что здесь вообще не this., а строго super. Потому что писать this. надо исключительно перед твоими кастомными методами данного наследника, которых нет в супер-классе. А если вызываешь унаследованный от суперкласса метод, будь добр так и писать: super.addChild(), super.dispatchEvent()
__________________
Reality.getBounds(this);

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Wolsh Посмотреть сообщение
В целом неплохо. Единственное, и ты сам чувствуешь что это костыль — иметь два типа для по сути одного события.. И проблема тут немного в другом месте — лучше бы иметь события класса ViewEvent и диспатчить из Вью именно их. Тогда и контроллеру не нужно будет импортить в себя ("знать") класс событий, которые распространяются внутри Вью. Безжалостная инкапсуляция не позволит контроллеру иметь доступ к внутренностям Вью через event.target.
Гы-гы. Я хотел одно событие в двух местах использовать и типа оптимизировать, а в итоге пришли к тому, что аж два разных класса наворотить пришлось. Забавно. Но логику я уловил, спасибо. Сейчас перепишем чуть-чуть. Получается, из модели во вью идут события одного класса, а из вью в контроллер - другого...

Цитата:
Ну и совсем в порядке ворчания — если начал писать this. то пиши его везде. Одинокий, висящий в воздухе "dispatchEvent" смотрится каким-то робким и неуверенным в себе. К слову, олдскульные холиварщики подняли бы тебя на смех, убеждая что здесь вообще не this., а строго super. Потому что писать this. надо исключительно перед твоими кастомными методами данного наследника, которых нет в супер-классе. А если вызываешь унаследованный от суперкласса метод, будь добр так и писать: super.addChild(), super.dispatchEvent()
Если честно, я не до конца чувствую логику этих обращений: this, super. Во многих туториалах чуть ли не перед каждым выражением этот this прилеплен. Насколько я понял из того-же Мука, с т.з. корректной компиляции и выполнения, это в большинстве случаев не критично (где критично, компилятор скажет). Некоторые фишки без this не прокатывают, например, при установке экранных координат я не могу написать x=10 без this. Плюс для себя я пишу, например, в меню this.addChild(button), потому что меню буквально добавляет кнопки "в себя". Наивно, но я так лучше собственный код читаю.

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

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Когда-нибудь тебе доведется впервые написать не dispatchEvent() и даже не this.dispatchEvent(), а какой-нибудь stepper.buttonPlus.dispatchEvent(), и тогда ты прочувствуешь, что может быть и такое, и что у метода должен быть хозяин (ну, не всегда, но то отдельный разговор), а вызов метода без объекта-хозяина делает код похожим на функциональное программирование, а не на ООП. Когда ты привыкнешь мыслить объектами, умеющими делать то-то и то-то, а не функциями, тебе самому захочется всегда указывать, КТО делает вот ЭТО.

По поводу событий я уже говорил, что Меню не обязательно иметь собственный класс события, можно обойтись коробочным DataEvent, заведя пару констант для различения типов прямо в классе Меню.
То есть: new DataEvent(Menu.SELECT, ..., button.id);
Для Вью же, с его РАЗНООБРАЗИЕМ событий, иметь собственный класс событий положено по рангу.
__________________
Reality.getBounds(this);

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Wolsh Посмотреть сообщение
Например, надо буквально завести себе привычку перед removeChild() ВСЕГДА проверять, есть ли парент и есть ли чайлд. Общепринятая конструкция выглядит так:
Код AS3:
if (displayObject.parent == this) this.removeChild(displayObject);
Даже когда тебе кажется что ну никак не может возникнуть ситуация, что меню не дитя Вью, иногда случаются совершенно волшебные казусы, вызванные особой очередностью выполнения обработчиков и кода текущего фрейма.
Я вот что хотел по этому поводу уточнить... Какой кайф в использовании такой конструкции? Например, произошёл вот такой волшебный казус, и меню случайно осиротело и перестало считаться ребёнком Вью. Если не писать условий, то, я подозреваю, схватишь ошибку, что заставит сесть и разобраться, в чём косяк. А в твоём случае объект просто не удалится из списка отображения. И ищи-свищи, в чём проблема. Или я неправильно понимаю?

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

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Цитата:
что заставит сесть и разобраться, в чём косяк.
Не заставит. Ошибка будет в рантайме.
Цитата:
А в твоём случае объект просто не удалится из списка отображения.
Мой случай — это когда объект УЖЕ удалился из списка отображения на момент вызова removeChild(). В 99% случаев проблема не в том, что у него другой парент)) а в том что его удалили раньше или еще не добавляли в отображение.
__________________
Reality.getBounds(this);


Последний раз редактировалось Wolsh; 08.11.2017 в 13:07.
Старый 15.11.2017, 16:17
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 67  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Wolsh Посмотреть сообщение
Шит в смысле "таблица", "сетка". Допустим у тебя 12 иконок для какого-то тулбара, все одного размера 24х24 пикселя.
Собираешь их на одной картинке вплотную друг к другу, допустим 4 иконки в ряду, 3 ряда. Шит.
Теперь тебе не надо 12 раз писать [Embed] и создавать 12 классов, эмбедишь только эту картинку.
В рантайме создаешь ее экземпляр и получаешь ссылку на битмапдату. В цикле как по двумерному массиву "нарезаешь" ее обратно на 12 картинок, каждую битмапдату 24х24 сохраняешь в массив. И когда надо отобразить, создаешь Битмап и передаешь ему нужную битмапдату из массива.
Друзья! Дошёл до программирования интерфейса, поэтому хочу вернуться к теме спрайтшитов. Подскажите, плиз, как лучше организовать. Будет прилично круглых иконок одинакового размера, плюс портреты персонажей - также все одного размера.

Пока имеем скачанный ShoeBox (с ним вроде всё понятно) и простенький ассет-менеджер, который умеет выдавать предварительно за-[embed]-женный Bitmap по строковому идентификатору. Понятно, что загруженный спрайтшит нарезаем на кусочки, BitmapData каждого помещаем в массив. В моём понимании это будет делать отдельный класс (или нет?). И главный вопрос, как наиболее удобно организовывать выбор нужного элемента? У меня пока модель выдаёт строковые идентификаторы (например, для нужной картинки с портретом). Как от них перейти к нужной битмапдате?

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

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Храни битмабы в Object или Dictionary. У них обоих допустимы строковые ключи. Я бы даже сказал, если ключи только строковые, то вполне хватит простого Object, в качестве ассоциативного массива
__________________
Ко мне можно и нужно обращаться на ты)

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

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

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


 


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


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