Форум Flasher.ru - Композиция: обращение вверх по иерархии

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

- - Композиция: обращение вверх по иерархии (http://www.flasher.ru/forum/showthread.php?t=204193)

Цитата:

Сообщение от in4core (Сообщение 1151503)

Wolsh - разозлился я на слово ПРЕДПОЛОЖЕНИЕ. Никаких тут предположений нет. Я четко знаю, что и когда видно и может ли удалится , будет ли такой функционал возможен или нет.

То, что с твоей точки зрения УВЕРЕНОСТЬ, для приложения - ПРЕДПОЛОЖЕНИЕ. А те, кто будут работать с твоим кодом, не обязаны знать что в данной точке выполнения приложения твоя светлая головушка решила держать кнопку на сцене. И не дай бог ее кто дернет!
К примеру я возьму твою игру да и загружу своим прелоадером, который кроме загрузки еще и рекламой занимается. И вот моя гениальная мысль состоит в том, что реклама должна выскакивать каждые 10 минут, а твоя игра не достойна стоять рядом с проплаченым банером. И простого опрозрачнивания игры мне не достаточно! Нет! Я ее вообще со сцены выдворю на время рекламного блока! Короче, сам спроси свою кнопку где ее сцена. А она, со слезами на глазах, только и скажет:

Цитата:

"Ты же обещал... Какая же я дура! Как я могла поверить в твои слова о пожизненной прописке на сцене???"

elder_Nosferatu - абсолютно прав. Но тут палка о двух концах, основной в том, что с моим кодом работать никто не будет, приложение будет полностью мое и мой же будет поддерживаться. В другом же случае, приходится думать и о других , без хардкода.
А по поводу примера - провал. Удаляй хоть всю игру, ошибка не всплывет. Подписка же не на стейдж на на маус эвент. По сему, после удаления ничего не произойдет, тем более после нового добавления. То есть в данном случае как ни крути, код не падает.

Вот же шь.. на сто раз разжевали, все без толку.
Как ты не поймешь, что время, когда возникает Событие, и время, когда выполняется обработчик — разное?
Тебе говорят, что между этими двумя моментами кнопка может быть убрана со сцены. Между. Была на сцене - послала событие - удалилась со сцены - вызвался обработчик. В котором ты обращаешься к стейджу.
Еще проще ситуация: послала событие - мышка сдвинулась на 1 пиксель - в обработчике ты делаешь хитТест и мышка не над объектом. Была над — во время события. Координаты в объекте События говорят, где мышка была во время События, а не во время работы обработчика.
Разжевано уже так, что даже другими словами не скажешь.
Мне вот, честно, поровну, работает твоя кнопка в твоих играх и пускай. Здесь речь не о том, как работает кнопка, а о том, как работает твой мозг программиста.
Просто ты привел пример кода, назвав его примером гибкости.
А теперь:

Цитата:

с моим кодом работать никто не будет, приложение будет полностью мое и мой же будет поддерживаться... Я четко знаю, что и когда видно и может ли удалится , будет ли такой функционал возможен или нет.

Это концептуальный хардкод. Он не плох и не хорош, он просто прямо противоречит понятию "гибкость". Больше вопросов нет.

Цитата:

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

Это конечно круто все. Только вот я не могу представить такой вот ситуации , кроме как если первой строкой хендлера будет выполнение удаления. Чисто теоретически есть и другие ситуации, не важно. Но это все в теории - на практике это будет работать нормально.
Я вот не спорю, что это некачественный подход, соглашаюсь, вопрос в другом, что такую ситуацию на практике поймать будет сложновато. С таким успехом можно привести и другие доводы из других областей, где точно так же НЕ ГИБКО выглядит все, но этим пользуются.

Цитата:

Просто ты привел пример кода, назвав его примером гибкости.

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

Цитата:

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

какая первая строка. Первая строка выполится после того как нначнет выполнение хендлер.

Короче. Напиши свою игру и дай поиграть посонам, скажи "надо поломать". Поломают.
Если для поделки на коленке то вполне ок. А наши QA такой баг выловят минуты за три. Потому что когда новое окно добавляется у них спецом в тест-кейсах прописано - проверить весь интерактив.

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

Main.as

Код AS3:

package 

{

        import flash.display.Sprite;

        import flash.events.Event;

        import flash.events.MouseEvent;

 

        public class Main extends Sprite 

        {

                public function Main():void 

                {

                        if (stage) init();

                        else addEventListener(Event.ADDED_TO_STAGE, init);

                }

 

                private function init(e:Event = null):void 

                {

                        removeEventListener(Event.ADDED_TO_STAGE, init);

                        // entry point

                        var button:In4CoreButton = new In4CoreButton();

                        super.addChild(button);

                        button.x = 100;

                        button.y = 100;

                        button.addEventListener(MouseEvent.CLICK, handlerButtonClick, false, 1); 

                }

 

                private function handlerButtonClick(e:MouseEvent):void 

                {

                        super.removeChild(e.currentTarget as Sprite);

                }

        }

}

In4CoreButton.as

Код AS3:

package  

{

        import flash.display.Sprite;

        import flash.events.MouseEvent;

 

        public class In4CoreButton extends Sprite 

        {

 

                public function In4CoreButton() 

                {

                        super.graphics.beginFill(0x000000);

                        super.graphics.drawRect(0, 0, 200, 50);

                        super.addEventListener(MouseEvent.CLICK, handlerClick);

                }

 

                private function handlerClick(e:MouseEvent):void 

                {

                        trace(this.stage);

                }

        }

}

Wolsh - что ты этим хотел показать? Я не понимаю тебя. Зачем мне удалять в хендлере при нажатии кнопку? Если ты не понял, я понимаю тебя, в какой ситуации это может произойти, я не ВИЖУ этой ситуации на практике. Хотя нет вру, на практике может быть и такая. Например кликанье по каким то шарам и удаление их после клика. В стандартной же ситуации , когда кнопка НИКОГДА не будет удалена, ибо это не требуется, такого просто не будет. Давай закроем это обсуждение, я не вижу смысла споров,
1) потому, что я согласен , что такая ситуация возможна
2) в моем приложении такой ситуации не сделать

Дикобраз - у всех есть свои QA, уж поверьте. Вот выложил старенький слот, тест сборку (эмулятор сервера ), поэтому на всякие Nan вместо текста, несовпадение символов и прочее, внимания обращать не стоит. Наша задача кнопка!!!
http://www.in4core.com/Slot.swf прошу, вот слот, в котором все кнопки такие. Плеер дебажный - поймаешь ошибку о которой мы говорим, буду очень признателен и обязательно извинюсь за свои споры перед каждым, кто оспаривал мои доводы.
За другие ошибки, тоже был бы признателен , вдруг найдете то, что не нашли игроки при тестах :).

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

Цитата:

Зачем мне удалять в хендлере при нажатии кнопку?

Затем, что больше она не нужна? О__о
В собственных слушателях внутри кнопки не может быть приоритетов — кнопка "конечный" элемент, не содержащий в себе интерактивных детей (99%... Возможны конечно хитрые варианты, следящие за перемещением мыши по кнопке, как например, Glow в таскбаре Win7.. но вряд ли они борются за приоритеты))). А вот у хозяина кнопки могут быть совершенно непредсказуемые планы по использованию ее событий, и он вполне может наставить приоритетов своим обработчикам, так что кнопка твоя будет ловить собственные события в последнюю очередь, что я и показал. Ее могут удалить, переместить, сделать неактивной, перекрыть и т.п. То, что тебе не хватает фантазии представить такие ситуации — не аргумент) Древний привел тебе пример — может понадобиться просто убрать все твое приложение (да хоть просто окно, в котором кнопка) со сцены из-за какого-то внешнего события по таймеру или от лоадера данных с сервера. Самый частый и простейший пример — кнопка закрывает собственное окно. Естественно, можно по-разному написать это действие. Но никто не обязан учитывать при этом внутреннюю реализацию твоей кнопки! Даже ты сам. Кнопка должна предъявлять минимум требований к хозяину. ЭТО называется гибкость, а не то что ты можешь кодом задать цвета для текстфилда, к которому вообще-то итак сделал публичный доступ, а состояния нарисовать в кадрах(!) и дать им правильные(!) метки (причем дизабленное состояние — нет, не можешь))), а наличие дизабленных овер/аут вообще не предусмотрено. Еще и текстфилд вставлен руками в ИДЕ, а значит ему в ИДЕ могут быть назначены такие специфические свойства, что ни в жизнь не догадаешься. Видишь? Я не о коде))

Babylon, я так ничего и не понял, о чем ты. Я не понимаю, что за безликий "контейнер", при этом таки имеющий свой класс (может, речь о чем-то типа лейаута? ну а как его поведение связано с наличием кнопки в контенте, нихт фернштейн? С каких пор лейаут как-то связан с поведением его контента? У тебя ячейки лейаута подписываются на события контента, что ли? Или все-таки логика?)
Если же речь о родителях-хозяевах кнопки, то мне непонятно, с какого перепугу я буду выдергивать кнопку из окна редактирования цвета и засовывать ее в контрол строки поиска, например, либо вообще давать кому-то доступ к ней. Она же инкапсулирована в хозяине. Я не собираюсь описывать через XML строение(!) контрола ColorPicker, давая каждому террористу возможность хватать любого ребенка и продавать за границу.

Кнопка должна наследоваться не от Sprite а от суперкласса CommonButtons
и оверрайдить нужные методы, а не писать super в конструкторе самой кнопки