![]() |
Как удалить объект со сцены по окончанию Tween?
Помогите, пожалуйста, новичку. Не получается удалить объект со сцены, в таком случае:
Код AS3:
Выдаёт ошибку Код:
ArgumentError: Error #2025: Предоставленный DisplayObject должен быть дочерним элементом вызывающего объекта.Удаления типа bar2.parent.removeChild(DisplayObject(bar2)) не работает и проверка с помощью contains() также. |
Код AS3:
|
Спасибо, что откликнулись, но к сожалению не работает, ошибка та же.
|
Что показывает?
Код AS3:
|
i.o., прошу прощения этот вариант работает! Огромное спасибо за помощь!
Код AS3:
|
Аварийное решение заключается в том, чтобы удалять объект из его родителя, не важно, кто это. Т.е., примерно так:
Код AS3:
|
Lazura, всегда пожалуйста ;)
mikhailk, а такое разве скомпилируется? |
i.o., а почему такое не должно скомпилироваться?
Другое дело, что это бросит RTE =) |
ок, напутал с классом
вот рабочий код: Код AS3:
|
Цитата:
mikhailk, в принципе достаточно было указать DisplayObjectContainer. Однако не поленился целый пример написать :) |
mikhailk, всё чуточку проще.
DisplayObject#parent имеет тип DisplayObjectContainer, в котором уже определен метод removeChild. Достаточно написать так: Код AS3:
|
ну да, не имеет ))
@Psycho Tiger да, так проще хотя, мне кажется, что если автор приложения не знает, откуда удаляет свои объекты, это не есть гут )) |
А я бы вообще так написал:
Код AS3:
|
Выкинет, если obj.parent подписан на Event.REMOVED и выкидывает в хэндлере исключение =)
Вообще даже в таких случаях я не ленюсь создать событие с bubbles=true, type="removeMe!!!", которое ловил бы ответственный сверху. |
Цитата:
|
Код AS3:
|
не, ну это уже перебор)
|
сорри за вопрос не по теме, а зачем тут super()?
|
вызвать конструктор суперкласса Sprite, если нет уверенности вызывается он по-дефолту до или после конструктора класса-наследника..
|
super, в случае его явного отсутствия в коде, всегда вызывается перед началом исполнения конструктора (т.е. вставляется первой строчкой конструктор).
Писать super() — это хороший тон и всё такое ) |
Цитата:
Просто кто-то решил, что это якобы "хороший тон", хотя на самом деле к тону это никак не относится. Просто люди выдают свои личные предпочтения за "хороший тон". |
@iNils, Отрицать конвенцию это точно не хороший тон.
Цитата:
|
Я так понимаю, без супера не обойтись, если необходимо вызвать конструктор супер класса с параметрами. Без параметров есть он или нет ни на что не влияет.
ок, ответ я получил. |
Цитата:
Цитата:
Чем больше правил, тем чаще их нарушают. Описывать нужно только ключевые моменты. Например. Название класса пишется с большой буквы. Это важный момент, так как помогает понять любому в чужом коде, что это класс. Описывать массив как [ 1, 2, 3 ], а не [1, 2, 3] или [1,2,3]. Извини, это бред. Всем и так понятно, что в обоих случаях это массив. |
Я когда-то был за её незыблемость?
Конечно, что-то из конвенции для меня кажется неправильным. И конечно, я делаю так, как удобно мне. Но именно конвенция должна лежать в основе кода. Если не будет фундамента — то точно придёт кто-то и скажет: "будем писать классы с маленькой, а переменные с большой!". Если есть какие-то аргументы (вплоть до не нравится), то от конвенции можно отступать. Если таких аргументов нету, то отступать не нужно. У тебя есть аргументы против написания пустого super() или что-то, что выдаст в этом дурной тон? |
Цитата:
|
А ещё не нужны пробелы и переносы строк. И там, и там компилятор всё сделает за нас.
Но и то, и то я делаю. Визуально проще. Почему проще с явным указанием super: не всегда конструктор имеет длину в 50 строчек. Он бывает и под 200, и под 300 (про рефактор, структуру класса и всё остальное умолчим). Это несколько экранов. Гораздо проще увидеть super() в самом верху и успокоится, что здесь всё стандартно. В противном случае нет той подсказки, которая сообщит мне, где же будет super. Мне придется пользоваться поиском. |
Цитата:
Цитата:
|
Цитата:
Цитата:
Цитата:
|
1. Ты следуешь 100% всех описанных там "норм"?
2. Создатель языка? Сомневаюсь. В том же адобовском хелпе эти нормы игнорируют. Как и в автоформате в родном Flash IDE, где официально должны были поддерживаться. 3. Это не официальные нормы, а рекомендуемые. И как я уже говорил выше, общий список норм вызывает сомнение в адекватности того, кто это писал. Поэтому я не вижу причин разделять то, что там написано. 4. Если это не твой код, то требовать от автора кода писать super в конструкторе в 200 строк, это как перед казнью отказываться от жирной пищи, потому что она вредит здоровью. Даже если представить, что там есть супер, то тебя не спасет от поиска тот факт, что он будет на 178 строке конструктора. |
1. Неа.
2. Рекомендации это не правила. Например, конвенция рекомендует скобку { переносить на следующую строку. Мне не очень нравится, я не соблюдаю. Но мой CS5 перенес его на новую. Требовать от редактора соблюдений всех конвенций это глупо. Завтра Adobe может взять тебя на работу и они изменятся. К тому же в моём понимании я имею возможность писать код как хочу, и почему автоформат должен крушить его в капусту я не понимаю. 3. Возможно, это писал тот, кому нечем было заняться. А возможно их писал самый талантливый в мире программист. Мы можем смотреть на них со своей колокольни и либо согласится, либо отвергнуть. Я повторюсь, что хороший тон — это поступать так, как рекомендуется. Будь плохим парнем, пиши так, как принято у тебя или как тебе нравится. Выпусти свою конвенцию рекомендуемых норм — и тогда мои слова возле твоей конвенции будут плохим тоном. Но пока весь мир пользует ту, что предлагает Адоуб бросаться словами вроде "это плохой тон!" не нужно. 4. Я по коду по F4 ползаю, а он переносит меня на сигнатуру конструктора. Я хотя бы буду знать, нужно мне искать его или нет. Получается — в мелких конструкторах super() писать не нужно, потому что бессмысленно, а в больших не нужно, потому что они уродливы и хорошим тоном их не поправишь? Правилами количество строк у конструктора/методов тоже не оговорено. Это то же как бэ хороший тон. (Отсутствие фантомного кэширования JIT компиляций у конструкторов не в счет.) Спор переходит в русло кто кого переспорит. Я за однотипность. super() в одних классах (не 1 строкой), super(...) в других, и отсутствие super`а в третьих. По мне это маленький шажок к каше в коде. Это как в конструкторах { ставить на следующей строке, а в методах на той же. |
Цитата:
|
Цитата:
А по какой сейчас пишут? |
Цитата:
В этом же FD код написан разными людьми и сочетает в себе чуть ли не все разновидности форматирования и написания кода. Хотя проект один. Так что зачем разводить тут холивар писать супер() или нет. Нравится - пиши, не нравится - не пиши. Мне вот например нравится переносить скобку на новую строку, хотя раньше писал на той же. Без проблем могу снова по-старому начать писать, был бы только смысл от этого. А вообще, Инилс дело говорит - если знаешь как работает конструтор без супера, то в лишних телодвижениях надобности нет ;) |
Цитата:
Я за соблюдение адобовской конвенции. Но строго соблюдать стоит только основные положения. Написание super() или расстановка пробелов (которые легко правятся форматтером) вещи второстепенные и непринципиальные. Хотя для упрощения сравнения файлов автоформатом лучше не злоупотреблять. |
FlashDevelop сам super не ставит
|
Цитата:
|
Может я конечно и путаю, но разработка в 99% случаев ведется под нативной IDE, FD и FB (порядок - произвольный). Номер 1 и номер 2 супер не ставят.
|
Цитата:
|
Это понятно.
Там вообще до черта всего настраивается. Но в исходной-то поставке этого нет? |
| Часовой пояс GMT +4, время: 19:59. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.