Гибкий пользовательский TreeItemRenderer, который меняется в зависимости от типа объекта? - PullRequest
0 голосов
/ 08 октября 2011

У меня есть элемент управления Flex-дерево, которое содержит дерево, заполненное различными типами объектов. Я хотел бы изменить метку элемента на основе этого типа (и других свойств). Я бы предпочел сделать это в пользовательском TreeItemRenderer, а не через функцию label или label.

Кажется, что что бы я ни делал, я не могу ни проверять, ни приводить объекты, и поэтому я получаю [Объектный объект] в узлах моего дерева. Вот мой рендер:

public class MyCustomTreeItemRenderer extends TreeItemRenderer {
    // Overriding to set the text for each tree node.      
    override protected function updateDisplayList(unscaledWidth:Number, 
                                                  unscaledHeight:Number):void {

        super.updateDisplayList(unscaledWidth, unscaledHeight);

        if (super.data) {
            trace("Rendering node:");

            if (super.data is MyClassA) { 
                trace("             MyClassA");
                super.label.text =  MyClassA(super.data).name
            }

            if (super.data is MyClassB) { 
                trace("             MyClassB");
                super.label.text = MyClassB(super.data).id;
            }
        }
    }

    public function NavigateTreeItemRenderer() {
        super();
    }

}

Изучение трассировки показывает, что я выполняю рендеринг узла, но я никогда не попаду внутрь ни одного из двух операторов if. Когда я запускаю в отладчике, я могу на самом деле свойства «данных», которые соответствуют MyClassA и MyClassB!

Ответы [ 2 ]

1 голос
/ 08 октября 2011
  1. В соответствии с вашими условиями вы можете использовать другой способ:

    переопределить данные набора открытых функций (значение: объект) { super.data = значение; label.text = ... }

  2. Но гораздо проще написать labelFunction

0 голосов
/ 11 октября 2011

Оказывается, меня укусила небольшая проблема, из-за которой компилятор ActionScript3 автоматически удалял мои классы из SWC моих удаленных служб, потому что он не обнаруживал прямой ссылки на эти классы. Поскольку эти объекты создаются экземплярами обработчиков результатов RemoteObject и помещаются в дочернюю коллекцию ArrayCollection, не было ссылок на них, которые компилятор мог бы обнаружить.

Когда это происходит, вместо того, чтобы генерировать исключение, реализация FlexO RemoteObject просто (и незаметно) превращает их в универсальный объект, тем самым сводя на нет значение их строго типизированного интерфейса.

Обходной путь должен был объявить переменную в каждом производном классе обслуживания для каждого типа объекта значения, который мог когда-либо появляться в их графах объектов.

...