for не выполняет всех интераций!!! О_О
 

Имеется следующий кусок кода:
вывод trace вот такой:
т.е. детей он насчитал 7, а интераций выполнил 4. Как это возможно? Бред какойто!

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

Ну так ты с помощью removeChildAt(i), уменьшаешь количество детей, поэтому все выполняется как положено.
Запиши в переменную количество детей, а потом используй его в цикле.

Добавлено через 14 минут
Хм, как бы им еще изменяться?

Если те всех нужно прибить я делаю

вот еще вариант

В примере, который привел 2ProxyGreen, нет смысла проверять наличие parent.

Тяжелое прошлое в кадрах? :)

Добавлено через 2 минуты
Можно еще так:

Самый быстрый, как ни странно, while (map_layer.numChildren) map_layer.removeChildAt(0);.

Нельзя так. Например может быть дисплейобджект, который на свой ремув утащит ещё что-нибудь с парента. У меня так текстфилды с кастомный бекграундом сделаны. Класс наследник текстфилда не может сделать addchild на себя. А нужен хитрый динамический фон. Для этого он на своём событии added на парента складывает бекграунд и свапается с ним, а на ремувед, удаляет свой бекграунд сам. Такми образом это внешне текстфилд и весь код который работает с текстфилдом, работает и с ним, а уже он сам за собой таскает свой фон.(естественно переопределены сеттеры размеров и координат). Так вот когда сремувится текстфилд, он ремувит фон, и приведённый код выпадет с ошибкой.

Это называется плохо спроектированный код. В вашем случае конечно так нельзя. Но это только в вашем случае.

Ну тогда:

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

В то-же время приведённый вами while (map_layer.numChildren) map_layer.removeChildAt(0); работает абсолютно корректно, и является более правильным способом удалить всех чайлдов. Т.к. событие removed может обрабатываться и каждый раз, когда вы пишете map_layer.removeChildAt(0) может выполняться сторонний код, который может изменять число чайлдов.

Между условиями "Удалим столько детей сколько их было в начале операции" и "Удаляем пока их совсем не останется" есть большая разница.

Что вам мешало создать своеобразный компонент?
Компонент - контейнер (наследник от DisplayObjectContainer), содержащий фон и обычный текстфилд.

Правда если кто-то особо злой на ремуве будет добавлять себя на место, можно и зависнуть. В моём случае на ремуве ещё один ремув, я думаю что это корректно, хотя и не красиво.

Добавлено через 37 секунд
Выше уже написал.

Ничего не мешает сделать текстфилд торчащим наружу ссылкой :)

Все равно неубедительно.
Ваш расширенный TextField прикладывает руки к своему родителю и ковыряется в его детях. При этом вам еще необходимо подписываться/отписываться от событий ADDED/REMOVED.
Не самый лучший вариант на мой взгляд.

Можно сделать полем вашего текстфилда спрайт. В который добавлять сам этот текстфилд и фон. Всё это делать и вообще создавать спрайт можно только если нужен навороченный фон. Ну там ещё перегрузить addChild/removeChild. Будут иногда некоторые проблемы, если этот текстфилд достается при помощи getChildByName/getChildAt, ну так не юзать их лишний раз, они вот точно зло =)

Решение -De- интересно, но всё равно не позволяет просто заменить new TextField() на фабрику и забыть. Моё позволяет. Мне оно самому не нравится тем, что лазит в парента, и я с радостью его переделаю на более адекватное, но пока таковых не нашёл.