Я так понял, что MRA -- это Mail.Ru Агент. Запустил пример MRA, и он мне написал, что компонента MRA_ChangeStatus нет. Дейcтвительно, на SVN нет файла MRA_ChangeStatus.ini

nesco, а говорил что не экстросенс

ну на работу примера наличие этого элемента никак не сказывается
------------ Дoбавленo:

Кроме того видимо придется делать элемент TreeView с иным способом обработки данных, а то существующее решение на этом примере демонстрирует полную не приспособленность для подобного рода задач.

Ну это и так понятно, что этот компонент для показа изменения статуса. Ну а я написал пост для констатации факта отсутствия части компонента на SVN.
------------ Дoбавленo:


А подробнее можно -- как преполагается проводить обработку

для начала о том, почему сейчас элементом TreeView очень сложно пользоваться при активной обработки данных, находящихся в нем.
1) невозможно построение дерева без знания номера родительского узла, который к тому же всегда меняется
2) после построения дерева практически нереально из схемы обратиться к какому-то конкретному узлу(требуется громоздкая операция вычисления его индекса)
3) к узлу невозможно привязать никаких дополнительных данных
4) отсутствие поиска
+ еще несколько не столь губительных, но неприятных моментов связанных со сложностью обработки дерева его нынешнем виде

Как можно бы было по другому сделать работу.
Для начала рабочей единицей данных будет МТ поток(кортеж).
Далее делаем св-ва элемента которые указывают какой элемент кортежа куда идет. С ходу видятся такие св-ва:
IconIndex - номер звена кортежа, который отвечает за иконку
CaptionIndex - номер звена кортежа, который отвечает за текст элемета дерева
DataIndex - номера звеньев кортежа, которые выдавать в поток при выборе элемента дерева
GroupIndex - номер звена кортежа, который отвечает за ID родителя нового элемента дерева
ID_Index - номер звена кортежа, который однозначно определяет элемент дерева(т.е. некое уникальное число или строка)

Примерно такого плана методы:
doAddNode(<кортеж>) - добавить элемент
doFindNode(<кортеж>) - поиск элемента в дереве
doSortNode(<кортеж>) - сортировка дочерних элементов указанного элемента
doDeleteNode(<кортеж>) - удаление элемента
doChangeNode(<кортеж>) - изменение элемента
....
onNodeClick(<кортеж>)
onNodeDblClick(<кортеж>)
onNodeBeginDrag(<кортеж>) - начало перетаскивания элемента
onNodeEndDrag(<кортеж>) - окончание перетаскивания
onNodeNotFound(<кортеж>) - родительский узел не найден

Принцип работы.
Например определяем св-ва так:

Тогда добавление сведется к вызову метода doAddNode с такими скажем данными
Поиск элемента с ID = 3
Поиск элементов, с Icon = 2
Смена заголовка элемента и его иконки с ID = 2

очевидно все эти команды сделаны на рассыпухе из элементов и впринципе подход позволяет формировать дерево как угодно при этом не нагромаждая схему кучей связей. Кроме того база может быть легко расширена для упрощения многих распространенных задач. Так же думаю понятно, что это не замена стандартного элемента. Это всего лишь альтернативный элемент для отображения древовидной структуры данных

Надо будет подумать о реализации. Единственное, что у меня не получилось, так это перетаскивание, сколько не пытался.

Dilma,
А в скором времени его ожидать можно?

Только не доставай, и будет тэбе счастье

в скором

Dilma, ты уже взялся за него или мне начать

первое. Еще мне пригодится в интерфейсе TIIconsManager прямой доступ к PImageList для того, чтобы передать в конструктор TreeView непосредственную ссылку на библиотеку иконок.

А как нужно, точкой, или функцией менеджера

Добавлено. Проверь, если что не так, то переправлю

все так:


пока переделывал схему на новое дерево, наткнулся на то, что PopupMenu у нас все еще не использует IconsManager. Кроме того туда тоже напрашивается такая же система с картежами - вся разница лишь будет в наборе индексов(Caption, Icon, ID, Enabled, Checked, Default).