Я так понимаю, Вы хотите использовать объект TreeView для создания/изменения/удаления записей таблицы? В принципе, такое возможно, но уж больно "муторно". Придется писать много кода, но, что более важно, у Вас постоянно будут возникать проблемы с идентификацией уровня вложенности узла.

Чтобы было понятно в чем проблема, представьте такую картинку в TreeView

0_1
--- 1_1
0_2

Вы находитесь на узле "0_1" и нажимаете кнопку "Добавить". Где должен быть создан новый элемент? На каком уровне? Как элемент, вложенный внутрь узла "0_1" или как элемент, расположенный после узла "0_1", но на том же уровне вложенности? Если как вложенный, то первый или последний?

Ну, т.е. какая картинка должна получиться в TreeView после нажатия кнопки "Добавить"

Вариант 1

0_1
--- 1_1
0_3 <-- Новый узел
0_2

Вариант 2

0_1
--- 1_1
--- 1_2 <-- Новый узел
0_2

Вариант 3

0_1
--- 1_2 <-- Новый узел
--- 1_1
0_2

Вариант 4

0_1
--- 1_1
------- 1_1_1 <-- Новый узел
0_2


TreeView - это объект, имеющий 2 измерения, а кнопка "Добавить" дает "интуитивно понятное" указание только на одно измерение (добавить после/перед текущим узлом).

Это то, что касается чисто технической стороны вопроса. А есть еще организационный вопрос. TreeView - как собака, друг, но друг ОДНОГО человека. Того, кого она считает "вожаком". Ко всем другим "человекам" в лучшем случае равнодушна.

То же самое с TreeView. TreeView - это объект, понятный только тому, кто занимается его ведением. Т.е. хорош только для ОДНОГО человека. Любой другой человек будет постоянно путаться в том, что и где в этом самом TreeView находится и поминать "тихим не злым словом" того, кто ТАК расположил узлы. Ну, ведь "совершенно очевидно", что вот этот узел должен быть внутри вот этого узла, а не внутри вон того...

В любом случае, я бы Вам не советовал использовать объект TreeView для модификации данных. Только для отображения. Т.е в обычном Grid создаете/изменяете записи. А в TreeView только отображаете результат

ClaymoreВладимирМ,

Только "Вариант 2" остальные исключаются!
Это Вы сейчас так думаете. Причем, насколько я понимаю, думаете только Вы. Мнением пользователей Вы не интересовались. О чем я и говорю. TreeView - друг ОДНОГО человека. В данном случае персонально Ваш.

ClaymoreЯ тут подумал, правильнее таблица будет выглядеть так:
Не то, чтобы описанная структура была не правильной, но она избыточна. Вам придется кроме генерации значения id еще как-то "сконструировать" генератор значения key.

Да, TreeView требует в качестве значения ключа узла символьное значение. Но ведь можно символьное значение получать "на лету" (в процессе построения дерева) из числового значения id. Например, переведя id в строку и добавив какой-нибудь символ. Например, "_".

Другими словами, вполне достаточно будет иметь такую структуру



А при заполнении TreeView формировать значение ключа примерно так




ClaymoreНе могу сообразить как правильно написать код в init формы form1, помогите)

Существует 2 принципиальные стратегии заполнения TreeView

Вариант 1

Сразу заполнить все узлы дерева на всех уровнях вложенности

Недостаток: при большом количестве узлов дерева потребует много времени на его заполнения. С точки зрения пользователя, форма будет открываться очень долго.

Правда, понятие "много узлов" сильно зависит от железа. Т.е. "много" - это когда время открытия формы больше 2..3 секунд. А сколько узлов можно успеть создать за это время напрямую зависит от используемого железа. От структуры дерева и алгоритма его наполнения время построения дерева зависит слабо.

Вариант 2

При открытии формы заполняется только первый уровень. А остальные уровни заполняются "по требованию". Обычно в момент первого раскрытия соответствующего узла. Так работает проводник в Windows.


Оба варианта требуют не очевидного программирования. Не сложного, а именно не очевидного. Не привычного.

Сразу заполнить все узлы дерева на всех уровнях вложенности

Проблема в том, что в TreeView невозможно сначала создать дочерний узел, а потом - родительский. Необходимо строить дерево строго "сверху вниз". Сначала родителя, потом потомка. На первый взгляд кажется ничего сложного. Но это при "гладкой" структуре заполнения таблицы как в примере. А если структура данных будет не "гладкая", ну, например

idparentid102153102150

Т.е. не получится просто просканировать таблицу сверху вниз и последовательно создавать узлы в дереве. Необходимо сначала "выстроить" записи в нужной последовательности. Замечу, что "хитрый индекс" здесь не поможет.

Если не создавать дополнительных полей сортировки с "обвязкой" в виде триггеров для поддержания этих полей в актуальном состоянии, то возможны два решения

1. Рекурсия
2. "Бесконечный" цикл с исключением ранее использованных значений

Системным ограничением FoxPro является ограничение на количество процедур, вызванных одна из другой. В данном случае это означает ограничение на количество рекурсий или количество уровней дерева. Для VFP9 - по умолчанию не более 128 вложенных процедур. Для младших версий - не более 32.

Если рассматривать решение с бесконечным циклом, то можно так