Как лучше хранить и редактировать дерево находящееся в массиве?

← →
CodeGen (2007-08-19 01:48) [0]

Как это лучше организовать?

Массив записей, каждая из которых содержит ссылку на предка, или на корень дерева. Это всё надо отображать и редактировать с помощью TTreeView. Кто-нибудь решал подобные задачи? Может поделиться опытом, как лучше такое делать?

← →
Kerk © (2007-08-19 02:15) [1]

А в чем конкретно проблема?

← →
CodeGen (2007-08-19 02:19) [2]

Как при перетаскивании мышью перестроить массив, например.

← →
MsGuns © (2007-08-19 02:20) [3]

Что хранится в "дереве" ?

← →
MsGuns © (2007-08-19 02:22) [4]

>CodeGen (19.08.07 02:19) [2]
>Как при перетаскивании мышью перестроить массив, например.

Причем здесь мышка до массива.

← →
CodeGen (2007-08-19 02:23) [5]

> MsGuns © (19.08.07 02:20) [3]
>
> Что хранится в "дереве" ?

Записи.

> MsGuns © (19.08.07 02:22) [4]
>
> >CodeGen (19.08.07 02:19) [2]
> >Как при перетаскивании мышью перестроить массив, например.
>
>
> Причем здесь мышка до массива.

Потому, что в TTreeView элементы можно перетаскивать мышью.

← →
Юрий Зотов © (2007-08-19 11:34) [6]

> CodeGen (19.08.07 01:48)
> Как это лучше организовать?

1. Если каждая запись содержит ссылку на предка, или на корень дерева, то никакой массив уже не нужен, достаточно просто хранить ссылку на корень.

2. С отображением и редактированием тоже просто - каждая запись содержит ссылку на TTreeNode (а не на запись), а эта TTreeNode в своем свойстве Data хранит ссылку на запись. Получаем однозначную взаимную связь между узлом визуального дерева и записью, а вся остальная визуалка уже практически готова в TTreeView.

← →
Petr V. Abramov © (2007-08-19 16:37) [7]

> Юрий Зотов © (19.08.07 11:34) [6]
при таком подходе и сам массив записей как бы уже ни к чему, все сидит в Data TreeNode`ов, да и ни к чему. Единственно, для чего может понадобиться - для какой-то быстрой обработки. Но тогда в массиве и ссылка на TreeNode ни к чему, достаточно из Data ссылки на элемент массива, для его перетасовки в случае мышиной возни в TreeView.

← →
Kerk © (2007-08-19 16:38) [8]

> [6] Юрий Зотов © (19.08.07 11:34)

ИМХО не стоит так сильно завязывать хранимые данные с способом их отображения

← →
Юрий Зотов © (2007-08-19 17:08) [9]

> Petr V. Abramov © (19.08.07 16:37) [7]

О чем и речь.

> Kerk © (19.08.07 16:38) [8]

Две завязки НЕИЗБЕЖНЫ в ЛЮБОМ варианте:
1. Визуальный элемент должен как-то ссылаться на элемент данных.
2. Визуальный элемент должен знать, как из ссылки на элемент данных получить отбражаемую строку.

И если вдуматься, то в [6] именно это и предлагается.

← →
CodeGen (2007-08-20 02:16) [10]

> Юрий Зотов © (19.08.07 11:34) [6]

> 1. Если каждая запись содержит ссылку на предка, или на
> корень дерева, то никакой массив уже не нужен,

Что значит ненужен? Данные находятся в массиве.

← →
ferr © (2007-08-20 02:19) [11]

> Что значит ненужен? Данные находятся в массиве.

Выкинуть массив.

← →
Черный Шаман (2007-08-20 03:26) [12]

> CodeGen (20.08.07 02:16) [10]

Присвой каждому элементу уникальный в сессии ID и ищи наследуй по нему.

> CodeGen (20.08.07 02:16) [10]

Данные находятся в ЭЛЕМЕНТАХ. А как элементы связаны между собой (в виде массива, дека, дерева или еще как) - это уже второй вопрос, но ясно, что два вида связи не нужны, одного достаточно.

Если каждый элемент имеет ссылку на родителя, получаем дерево. Зачем еще какие-то массивы?

← →
Algol (2007-08-20 12:56) [14]

> Две завязки НЕИЗБЕЖНЫ в ЛЮБОМ варианте:
> 1. Визуальный элемент должен как-то ссылаться на элемент
> данных.
> 2. Визуальный элемент должен знать, как из ссылки на элемент
> данных получить отбражаемую строку.

Совсем не факт. В MVP визуальный компонент может даже не знать о модели. Дело визуального компонента - "отобразть то что скажут"

← →
имя (2007-08-20 22:32) [15]

Удалено модератором

← →
CodeGen (2007-08-21 06:00) [16]

> Юрий Зотов © (20.08.07 07:49) [13]
>
> > CodeGen (20.08.07 02:16) [10]
>
> Данные находятся в ЭЛЕМЕНТАХ. А как элементы связаны между
> собой (в виде массива, дека, дерева или еще как) - это уже
> второй вопрос,

Нет они находятся в массиве. Это менять нельзя.

> Если каждый элемент имеет ссылку на родителя, получаем дерево.
> Зачем еще какие-то массивы?

А если бы элементы массива не имели ссылок на родителей, то как бы мы узнали какой к какому прикреплён?

Есть в общем случае два способа отображения древовидных данных (не обязательно взятых из БД):
- полная загрузка ВСЕХ данных в дерево (по схеме, приведенной ЮЗ, или близкой к ней) для отображения - в этом случае данные с диска (таблицы) должны быть полностью отображены в ОП (в виде объектов типа record или специально разработанного класса), при этом каждая такая запись однозначно связана со "своим" узлом дерева.
- узлы дерева содержат только ключи (наименования) записей данных, представляющих группу записей, содержимое же групп отображается в таблице, "привязанной" к текущей группе (узлу дерева) - в этом случае дерево может быть никак не связано с собственно "массивом" записей данных, вместо этого ТЕКУЩИЙ УЗЕЛ связан с отображающим датасетом ЗАПРОСОМ.

Как лучше хранить и редактировать дерево находящееся в массиве? Найти похожие ветки