DisplayObjectContainer как на его основе написать класс?

[Bletraut]

Ну вот всем известно что Sprite наследуется от DisplayObjectContainer, а Shape от DisplayObject, но вот как самому написать свой класс что бы его можно было еще и выводить на экран наследуясь только от DisplayObject или DisplayObjectContainer?

Я знаю что эти классы абстрактные, но как всё-таки был написан Shape?

[in4core]

Ничего непонятно. В чем проблема сделать extends DisplayObjectContainer например и получить свой собтсвенный спрайт?

[Bletraut]

Его потом методом addChild добавить нельзя.

[Final Hope]

Чем спрайт-то не нравится? И рисуется, и добавляется...

[Bletraut]

Дело не в том нравится или нет, а в том что я хочу понять природу создания ХД

[Final Hope]

http://help.adobe.com/ru_RU/ActionSc...0204-7f3f.html

[Tails]

Нельзя наследоваться от DisplayObject или DisplayObjectContaner, расширяйте спрайт, шейп или мувиклип.

[Psycho Tiger]

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

Ничего непонятно. В чем проблема сделать extends DisplayObjectContainer например и получить свой собтсвенный спрайт?

У меня не получается

[Wolsh]

Хелп:

Сам класс DisplayObject не содержит API-интерфейсов для визуализации содержимого на экране

, ну а вам-то удастся их добавить?))) Дисплейные классы реализованы в плеере. То есть именно предоставляют нам API — интерфейс для отображения чего-то на экране. Интерфейс нам доступен, а реализация, конечно же, нет. Так что создать свой собственный ДО невозможно.

Чем спрайт-то не нравится?

Да много чем. Какой-бы свой класс вы от него ни унаследовали, любой идиот может запихать в него что угодно методом addChild(). Вот вы пишете галерею, и делаете в ней метод addImage() для добавления изображений. В этом методе вы регистрируете картинку в массиве, привязываете к ней данные и размещаете в соответствии с общей сеткой-лейаутом. Но при этом снаружи ничего не стоит засунуть в эту "галерею" любой ДО бульварным addChild(), со всеми вытекающими. Безо всякой регистрации и безо всякого контроля над ним со стороны галереи. А ведь по сути практически всегда, когда вы пишете наследника Спрайта, вы предполагаете добавлять в него только совершенно определенные объекты и никогда не думаете делать это ИЗВНЕ методом addChild(). В 65% случаев все внутренние объекты создаются самим этим классом ВНУТРИ, и в 30% — добавляются извне через специальный публичный метод, содержащий фильтр Типа добавляемого объекта, и берущий его "на контроль", прежде чем добавить в свой список отображения.
Очень хочется надеяться, что в каком-нибудь AS4 (а лучше просто в новом плеере) появится новый класс контейнера, у которого addChild() будет protected — захотел, сделал в наследнике API для добавления в этот контейнер детей (причем нужного типа), не захотел — не сделал. То есть та мутация, которую на низком уровне произвели с TextField и SimpleButton: вроде бы контейнер, а публично добавить addChild'ом ничего нельзя.

[СлаваRa]

можно запретить вызовы addChild и т.д. для этого есть соотвествующие метатеги