вопрос по addChild

[fishbounce]

если:
var s:Sprite = new Sprite();
var u:Box= new Box(); // например Box
то
u.addChild(s);
вызывает ошибку
cannot convert flash.display::Sprite@854e7e6 to mx.core.IUIComponent.
Хотя, по идее, у метода addChild(val: DisplayObject).

Понятно, что Sprite не ипмплементирует mx.core.IUIComponent, а, как видно, контейнер Box этого хочет.

Но как тогда быть, если я хочу "прибить" Sprite instance к Box instance?
(например, нарисовать че-нить в Sprite программно, а потом засунуть в Box).

[BlooDHounD]

Box - должен быть наследован от Sprite

[fishbounce]

в том то и дело, что Box - это mx.containers.Box, который наследуется от Container -> UIComponent -> Sprite.
Но, факт есть, возникает вышеописанная ошибка.

UP!

[7thsky™]

в классе mx.core.Container метод addChild перегружен - не смотря на то что в документации он принимает DisplayObject, скорее всего addChild (child:IUIComponent) или ошибка возникает внутри переписанного метода, где пытаются привести аргумент к IUIComponent

[fishbounce]

ок, это понятно.
Но как тогда быть?
Т.е. я не могу добавить объект Sprite, MovieClip... (все , что выше UIComponent'ов в цепочке наследования) как child в какой-нибудь UIComponent.
В принципе, вопрос был в этом.
Мне кажется, что такая ситуация "не есть хорошо")

[fishbounce]

такая ситуация наблюдается только с instance'ами наследников mx.core.Container.
C наследиками UIComponent (например, Button) все нормально

[7thsky™]

ок, это понятно.
Но как тогда быть?
Т.е. я не могу добавить объект Sprite, MovieClip... (все , что выше UIComponent'ов в цепочке наследования) как child в какой-нибудь UIComponent.
В принципе, вопрос был в этом.
Мне кажется, что такая ситуация "не есть хорошо")

в принципе это логично, так ты имеешь библиотеку компонентов, нормально что компонент может добавить в себя только компонент

[Antares]

На уровне UIObject это реализовано так:

1. Каждый компонент -- визуальный класс (наследним мувиклипа).
2. Создание включает в себя либо аттач, либо createEmptyMovieClip c Object.registerClass

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

[7thsky™]

На уровне UIObject это реализовано так:

1. Каждый компонент -- визуальный класс (наследним мувиклипа).
2. Создание включает в себя либо аттач, либо createEmptyMovieClip c Object.registerClass

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


Миша, ты про что это :) этож АС3 :)

[Antares]

А ты думаешь внутри везде все другое?:) У меня вот нет 100% уверенности

[fishbounce]

На уровне UIObject это реализовано так:

1. Каждый компонент -- визуальный класс (наследним мувиклипа).
2. Создание включает в себя либо аттач, либо createEmptyMovieClip c Object.registerClass

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

Я тоже не вижу причин) однако, не цепляет контейнер простейшие классы, от которых он наследован:(

Я искал в гугле что-нибудь на эту тему: нашлось 2 ссылки (та же проблема) на форумы - вроде французский и польский что ли... в этих языках я не силен:( и насколько видно (мое предположение:)) из тамошних дискуссий, четкого ответа нет...

Так что вот так...
Косяк какой-то.

[7thsky™]

посмотрел в дебаггере у функции addChild у mx.core.Container есть локальная переменная uiChild

то есть происходит что-то вроде

public override function addChild (child:DisplayObject):DisplayObject {
var uiChild:IUIComponent = IUIComponent (child);
if (uiChild == null) {
throw new TypeError ('Error');
} else {
....
}
}


З.Ы. Антарес, твои темные намеки не понятны, а предложение "...Создание включает в себя либо аттач, либо createEmptyMovieClip c Object.registerClass...", вообще пёрл в контексте АС3, уж если АС3 это доделанный АС1, то уж от этих трех методов избавились в первую очередь.

[Antares]

Или обернули их еще в один декоратор :)

[7thsky™]

Нет не обернули, так как такая конструкция не дает возможности копировать ЗАГРУЖЕННЫЙ МУВ из одного парента в другой (без переиницилизации этого мува), а если есть конструкция которая позволяет это делать то нету надобности в createEmptyMovieClip (), attachMovie (), createTextField (), Object.registerClass ()

[fishbounce]

посмотрел в дебаггере у функции addChild у mx.core.Container есть локальная переменная uiChild
....

спасибо...
все это, конечно, хорошо.
но вопрос остается: что делать:)?
забить?

[7thsky™]

наследуй не от Spite, а от UIComponent

[BlooDHounD]

что делать ... что делать .... а чего собсвенно пытаемся добиться? а то как-то отвлеклись от основй темы и перешли непонятно куда.

[fishbounce]

Добиться того, чтобы в контейнер (объект mx.core.Container) можно было "вставить" addChild'ом объект Sprite.
Но, я так понимаю, обсуждать здесь больше нечего...
Придется действительно вместо Sprite использовать более громоздкий UIComponent.

[Antares]

Спросил бы во Флекскодерз -- дали бы ответ сами Адобовцы. Они знают побольше нас.

[BlooDHounD]

Я реально наверно не понимаю. Зачем это делать?

[fishbounce]

наверное, не понимаешь. Я в первом посте, в принципе, пытался объяснить.

[Antares]

Да какая разница, зачем. Просто непонятно, почему не дает. И это уже само по себе интересно.

[7thsky™]

ну наверно как первая нормальная библиотека компонентов, все что добавляется внутрь компонента, регистрируется в LayoutManager, и чтобы он мог этим чайлдом мог нормально тусовать тут должен реализовывать интерфейс IUIComponent. я же говорил что метод переписан в mx.core.Container, в переписанном методе и происходит попытка привести к IUIComponent.

[fishbounce]

во flexcoders примерно то же самое ответили. В качестве выхода, чел предложил сначала Sprite запихнуть в UIComponent - это работает, а потом UIComponent уже в Container. Таким образом, все нормально.

[Diomas]

сам недавно наткнулся на проблему. Если еще актуально, вот решение:
var s:Sprite = new Sprite();
var u:Box= new Box();
u.rawChildren.addChild(s);

[etc]

Я думаю, год назад уже разобрались.