nesco писал(а):
А подробнее можно -- как преполагается проводить обработкудля начала о том, почему сейчас элементом TreeView очень сложно пользоваться при активной обработки данных, находящихся в нем.
1) невозможно построение дерева без знания номера родительского узла, который к тому же всегда меняется
2) после построения дерева практически нереально из схемы обратиться к какому-то конкретному узлу(требуется громоздкая операция вычисления его индекса)
3) к узлу невозможно привязать никаких дополнительных данных
4) отсутствие поиска
+ еще несколько не столь губительных, но неприятных моментов связанных со сложностью обработки дерева его нынешнем виде
Как можно бы было по другому сделать работу.
Для начала рабочей единицей данных будет МТ поток(кортеж).
Далее делаем св-ва элемента которые указывают какой элемент кортежа куда идет. С ходу видятся такие св-ва:
IconIndex - номер звена кортежа, который отвечает за иконку
CaptionIndex - номер звена кортежа, который отвечает за текст элемета дерева
DataIndex - номера звеньев кортежа, которые выдавать в поток при выборе элемента дерева
GroupIndex - номер звена кортежа, который отвечает за ID родителя нового элемента дерева
ID_Index - номер звена кортежа, который однозначно определяет элемент дерева(т.е. некое уникальное число или строка)
Примерно такого плана методы:
doAddNode(<кортеж>) - добавить элемент
doFindNode(<кортеж>) - поиск элемента в дереве
doSortNode(<кортеж>) - сортировка дочерних элементов указанного элемента
doDeleteNode(<кортеж>) - удаление элемента
doChangeNode(<кортеж>) - изменение элемента
....
onNodeClick(<кортеж>)
onNodeDblClick(<кортеж>)
onNodeBeginDrag(<кортеж>) - начало перетаскивания элемента
onNodeEndDrag(<кортеж>) - окончание перетаскивания
onNodeNotFound(<кортеж>) - родительский узел не найден
Принцип работы.
Например определяем св-ва так:
IconIndex = 1
CaptionIndex = 0
DataIndex =
GroupIndex = 2
ID_Index = 3
Тогда добавление сведется к вызову метода doAddNode с такими скажем данными
doAddNode("Parent node1 name", 0, -1, 1, "какие-то пользовательские данные")
doAddNode("Node1 name", 1, 1, 2, "какие-то пользовательские данные")
doAddNode("Node2 name", 1, 1, 3, "какие-то пользовательские данные")
doAddNode("Parent node2 name", 0, -1, 4, "какие-то пользовательские данные")
doAddNode("Node1 name", 2, 4, 5, "какие-то пользовательские данные")
doAddNode("Node2 name", 2, 4, 6, "какие-то пользовательские данные")
doFindNode("", -1, -1, 3, "")
doFindNode("", -1, 2, -1, "")
doChangeNode("New node name", 0, -1, 2, "")
очевидно все эти команды сделаны на рассыпухе из элементов и впринципе подход позволяет формировать дерево как угодно при этом не нагромаждая схему кучей связей. Кроме того база может быть легко расширена для упрощения многих распространенных задач. Так же думаю понятно, что это не замена стандартного элемента. Это всего лишь альтернативный элемент для отображения древовидной структуры данных