Переименование Itema в TreeView

[Dimyan]

Как сделать так чтоб (ну например при двойном клике) Item в TreeView перешол в состояние переименования (т.е. его имя стало свободно для редактирования и первоночально выделено, как в проводнике)?

[Alf]

Dimyan, я попробовал вот так:

Код:

private void treeView1_DoubleClick(object sender, System.EventArgs e)
  {
    treeView1.SelectedNode.BeginEdit();
  }

По двойному щелчку на узле его метку можно редактировать с клавиатуры, если ты хотел именно этого.
Чтобы метки узлов можно было менять, не забудь добавить где-нибудь в программе строчку:

Код:

this.treeView1.LabelEdit = true;

иначе возникнет исключение.

[Alf]

Dimyan, куда пропал?
Рассказывай, получилось так, как ты хотел, или дальше копать нужно?

[Dimyan]

Alf, работы много было. Спасибо, Альф, твой совет как всегда в точку
Следующий вопрос по теме:
У меня в программе некоторые Item'ы выполняют (если провести анологию с проводником, правда программа ни какого отношения к файл менеджерам не имеет) роль как бы папок (тем) в них могут содержатся под темы (как бы подкаталоги) и на любом уровне вложенности могут быть обыкновенные итемы (как бы файлы, если сравнивать с проводником). Добавление того или инного итема осуществляется выбором соответствующего пункта меню, при этом если ни один итем не выбран то (в зависимости от выбора тема или просто итем) новый создается в корне, если какой то выбран то создается его подитемом.

Дак вот проблема как все это осуществить
Ну или если точнее как мне пометить что один это папка, а другой напимер это просто вложеный  в папку элемент.

[Dimyan]

Да уж лингвиста из меня не выйдет
Надеюсь хоть болие мение понятно изяснился

[Alf]

Да уж лингвиста из меня не выйдет
Надеюсь хоть болие мение понятно изяснился

Почти  
Все-таки человеческий язык содержит слишком много неоднозначностей, придется уточнить один момент. Что ты подразумеваешь под словом "пометить"? Ты хочешь, чтобы человек визуально мог отличить "подкаталог" от простого "элемента", как в проводнике, или же их должна отличать программа?

Если первый вариант, визуальное определение, то напрашиваются два решения. Первое - элементарное, не придется делать вообще ничего. Ведь если узел содержит дочерние узлы, рядом с ним появляется плюсик, позволяющий раскрыть ветку дальше. А если узел конечный, элементарный, то возле него ничего нет.
Если же ты хочешь сделать различие между "подкаталогами" и "элементами" более ярким, можно воспользоваться свойством TreeNode.ImageIndex. Только тебе придется подобрать или нарисовать самому маленькие пиктограмки для того и другого и поместить их в TreeView.ImageList, и тогда твое приложение будет выглядеть совсем роскошно.

Если же тип узла дерева должна различать программа, то ей достаточно определить количество дочерних узлов для данного. Это тоже сделать несложно. Каждый узел дерева имеет свойство Nodes, это коллекция дочерних узлов. Достаточно сравнить с нулем количество дочерних узлов:

Код:

if (currNode.Nodes.Count == 0) // элемент
  {
    ...
  }
else // подкаталог
 ...

Надеюсь, это именно то, что тебе нужно?

P.S. В отличие от предыдущего ответа, эти варианты я не проверял в Visual Studio, поэтому не гарантирую 100% точность.

[Dimyan]

Alf, про визуальное оформление я знаю, даже научился с ним работать, а надо мне как раз различать программно. И сразу вопрос: допустим я создаю итем (тему) и у него еще нет никаких дочерних итемов, получается что свойство Nodes будет так же содержать 0, как и у тех итемов которым по определению нельзя содержать вложения (т.е. по аналогии с проводником - файлы)
Как тогда выбрать между так скажем пустой папкой и файлом?

P.S: Визуально они тоже должны различатся, но я думаю с этим справлюсь

[Dimyan]

Alf, про визуальное оформление я знаю, даже научился с ним работать, а надо мне как раз различать программно. И сразу вопрос: допустим я создаю итем (тему) и у него еще нет никаких дочерних итемов, получается что свойство Nodes будет так же содержать 0, как и у тех итемов которым по определению нельзя содержать вложения (т.е. по аналогии с проводником - файлы)
Как тогда выбрать между так скажем пустой папкой и файлом?

P.S: Визуально они тоже должны различатся, но я думаю с этим справлюсь

[Alf]

... И сразу вопрос: допустим я создаю итем (тему) и у него еще нет никаких дочерних итемов, получается что свойство Nodes будет так же содержать 0, как и у тех итемов которым по определению нельзя содержать вложения (т.е. по аналогии с проводником - файлы)
Как тогда выбрать между так скажем пустой папкой и файлом?

Понял проблему. Конечно, одним подсчетом вложений тут не обойтись, получается...
Тогда предлагаю такое решение. У TreeNode есть еще полезное свойство Tag, оно оставлено на усмотрение программиста, и там можно хранить что угодно. Если ты в момент создания узла дерева знаешь, будет ли это элемент или подкаталог, ты можешь сделать соответствующую пометку в этом свойстве. Думаю, что это должно помочь.

[Alf]

Dimyan, кстати, я поторопился с ответом и прохлопал самое простое решение...  :oops:
Ведь если ты уже научился различать визуально элементы и подкаталоги, значит, у них и так уже различные значения свойства TreeNode.ImageIndex, и можно этим воспользоваться без дополнительных уловок...

[Dimyan]

Alf, мое тебе неустанное спасибо
Действительно элементарный выход что тот, что другой
"Все гениальное - просто" (с)
И последний вопрос, чтоб уж добить  
Как эту структуру древовидности сохранить в файле? Сами процедуры сохранения не важны да и тип файла, то есть я имею в виду какое свойство элемента сохранять, чтоб потом (при загрузке) можно было возобновить структуру?
Я думал что можно сохранить путь элемента (не помню как называется функция возвращающая путь элемента, но знаю точно что она есть), но как потом по этому пути его востанавливать? Или может каким нибудь другим методом?

[Alf]

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

Какое именно свойство - я затрудняюсь ответить, поскольку ровным счетом ничего не знаю о тех данных, которые у тебя хранятся в структуре дерева.
Могу рассказать, как это делал я, когда работал с классификаторами. Там узлы дерева представляли собой различные категории сельхозпродукции, причем любая категория могла делиться на подкатегории. Ну что-то вроде "Продукты растениеводства - Зерновые - Пшеница - Твердые сорта - ..." и т.д. Эта структура хранилась в реляционной базе данных. При этом в поле Tag я хранил ключ соответствующей записи, так что обеспечивалось однозначное соответствие информации в базе и в дереве. В этом случае вопрос сохранения вообще не стоит, т.к. структура с самого начала грузится из базы данных, и все ее изменения также на лету отражаются в базе.
Если работать с базой данных для твоего приложения слишком громоздко (хотя, наверное, это единственный способ, если программа рассчитана более чем на одного пользователя), то можно рассмотреть вариант с выгрузкой данных в формате XML, это должно сохранить структуру дерева.
Еще один вариант, если тебе достаточно хранить только название узла, - простой текстовый файл. В начале каждой строчки ставим номер уровня, а потом перечисляем все дочерние узлы для данного. Например:

Код:

1 Продукты растениеводства
  2 Зерновые
    3 Пшеница
      4 Твердые сорта
        5 Сорт 1
        5 Сорт 2
        5 сорт 3
      4 Мягкие сорта
        5 Сорт 4
        5 Сорт 5
    3 Овес
      4 Сорт овса 1
      4 Сорт овса 2
  2 Овощи
.....

Можно для улучшения читаемости добавить сдвиги, как в примере. При отладке наверняка придется не раз проверить список, и такой формат позволит быстрее разобраться.
Последний вариант очень легко реализовать в виде рекурсивной процедуры. "Сохранить узел" - значит вывести номер уровня дерева, затем имя узла, а потом повысить номер уровня на 1 и сохранить дочерние узлы. Тогда, чтобы сохранить все дерево, достаточно сохранить корневой узел, дальше рекурсия раскрутится сама собой.
Со считыванием тоже проблем не должно быть.
Если эти варианты не подходят, расскажи, в чем именно. Будем думать дальше.

[Dimyan]

В принцепе подходят, только я не совсем понял.
А программа моя какраз работает с БД. Происходит это следующим оброзом:
т.к. я еще только учусь (благодоря тебе же) ADO.Net, а литературы у меня нет дополнительной чтоб использовать напримар Access (просто его я знаю немного, а SQL ваще ни как), то решил пользоваться просто dataSet и сохранять все это в XML (у него стандартное сохранение там такое, поэтому и выбрал). в общем две таблици (может я и структуру не правильно создал, я ведь в первый раз)
1-ая: два столбца:
 :arrow: ключевой, просто счетчик
 :arrow: второй тема (т.е. папки как бы)

2-ая:
 :arrow: ключь (счетчик)
 :arrow: поле для связи с первой таблицей (первым ее столбцем)
 :arrow: имя элемента в дереве (который как бы файл если с проводником сравнивать) считывает информацию из предедущего столбца, чтоб знать каой папке он принадлежит
 :arrow: текстовое поле, содержит просто некоторый обьем текста каторый должен отображаться в richTextBox при счелчке по итему в дереве

мне вроде понравился способ с рекурсией но как узнать номер уровня элемента или для моего случая подходит болие простой способ?

[Alf]

Dimyan, давай по порядку. До рекурсии еще доберемся, а сейчас разберемся с базой для начала.

Идея с двумя таблицами мне не понравилась по многим причинам.
Во-первых, неплохо бы для каждого узла дерева иметь уникальный идентификатор. Если таблиц две, то и независимых счетчиков получается два, отсюда возможные коллизии. Конечно, можно настроить их так, чтобы во второй таблице начинать счет не с 0, а, допустим, с 1.000.000.000. Но все равно не слишком красивое решение.
Во-вторых, поскольку в каждой "папке" могут быть как "файлы", так и другие "папки", при построении дерева придется нырять в обе таблицы. А это не очень удобно.

Предлагаю следующую структуру полей единственной таблицы:

1) NodeID - счетчик.
2) ParentID - идентификатор родительского узла. Для корневого - 0, как указатель, что родителя нет (сирота).
3) NodeName - текстовая метка узла (которая в дереве пишется).
4) NodeType - тип узла (0 - "файл", 1 - "папка").
5) NodeText - текстовое содержимое узла - "файла" (в случае, если NodeType=0).

Тогда у нас будет одна-единственная таблица, в которой хранится вся структура дерева. Как тебе такой вариант?

[Dimyan]

Alf, надо было мне сразу тебе изложить структуру, конечно меня все устраивает, ведь я учусь и тебя воспринемаю как непосредственного своего учителя, тем болие я привык прислушиватся к критике. Еще меня устраивает вариант с одной таблицей по тому что исчезает проблема работы со связями и я могу более углубится в изучение работы с таблицей (полями и значаниями), а при наличии опыта работы с ними можно будет браться и за связи между таблицами и т.д. Я вообще решил поработать со так сказать стандартными таблицами, чтоб более подготовленым подойти к изучению работы с провайдерами.

Вопрос только по полю  ParentID. Я понял так что 1- это когда элемент имеет родителя, но родитель может так же иметь родителя, но как же тогда восстановить структуру при загрузке?

[Alf]

...
Вопрос только по полю  ParentID. Я понял так что 1- это когда элемент имеет родителя, но родитель может так же иметь родителя, но как же тогда восстановить структуру при загрузке?

Нет, из этого поля можно извлечь гораздо больше пользы, если хранить в нем не сам факт, что элемент имеет родителя, а ключ этого самого родителя, то есть значение NodeID родительского узла. Собственно, это что-то вроде указателя в программе на С. А если это поле объявлено первичным ключом, то по нему будет построен индекс, и поиск будет производиться весьма эффективно.
Продолжаем наш пример:

Код:

1000  Пшеница             0776 1
1001  Твердые сорта       1000 1
1002  Сорт 1              1001 0
1003  Сорт 2              1001 0
1004  Сорт 3              1001 0
1005  Мягкие сорта        1000 1
1006  Сорт 4              1005 0
1007  Сорт 5              1005 0

(текстовое поле для "файлов" я не заполнял).
Теперь, если тебе понадобится, например, вытащить все дочерние узлы для "Пшеницы" (NodeID=1000), это можно сделать простым SQL-запросом:

Код:

SELECT *
FROM tbTREE
WHERE (ParentID = 1000)

При этом ты не обязан упорядочивать таблицу таким образом, чтобы соседние узлы находились в соседних строках (а с упорядочением строк в реляционных базах дело вообще обстоит неважно, как я уже говорил в теории, и на порядок строк закладываться нельзя ни в коем случае). А это значит, что добавлять новые узлы к дереву ты можешь в любое время, дописывая новые строки в таблицу и задавая значение поля ParentID.
Раскручивать дерево при запуске программы тоже очень просто. Сначала выбираем все узлы, у которых ParentID=0, а затем рекурсивно повторяем эту процедуру для каждого узла, пока не пройдем по всем.

[Dimyan]

Alf, я все понял, обязательно попробую.
Только как узнать (если делать рекурсию при загрузке) о дастижении последней записи в базе?

[Alf]

Alf, я все понял, обязательно попробую.
Только как узнать (если делать рекурсию при загрузке) о дастижении последней записи в базе?

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

[Dimyan]

Alf, чето я совсем запутался
Хорошо, рекурсией я востановлю все "папки", а как же тогда востановятся "файлы"?

[Dimyan]

Хотя если я правильно предположил, то нужно с помощу SQL запроса вытаскивать узла ("файлы") каждой "папки" и вставлять их в дерево. Правильно?
Но только как тогда лучше поступить, делать это прям во время работы рекурсвного метода? т.е. рекурсия находит "папку" вставляет ее в дерево, потом запрос находит ее "файлы" и вставляет их в нее?

[Alf]

Dimyan, если со структурой базы тебя все устраивает, то можно перейти к процедурам работы с ней.
Прежде всего при старте программы мы должны построить дерево в соответствии с содержимым базы данных.
Сначала рассмотрим процедуру заполнения узла дерева (чтобы избежать ненужных сейчас деталей, я использовал псевдокод): CurrNode - данные о текущем узле, ParentTN - узел дерева, к которому мы прилепляем ветку:

Код:

procedure FillNode(Node CurrNode, TreeNode ParentTN)
{
Дорисовываем к узлу ParentTN дочерний CurrTN;
Заполняем новый узел CurrTN данными из CurrNode;
if (CurrNode.Type==0) // текущий узел - "файл"
  return; // дочерних узлов у "файла" нет, больше тут делать нечего
/* получить перечень дочерних узлов CurrNode/
    SiblingNode - коллекция узлов */
SiblingNode = SELECT * FROM tbNODE WHERE (ParentID = CurrNode.ID);
// пройтись по всем дочерним узлам
foreach (Node N in SiblingNode)
  FillNode(N, CurrTN);
}

А теперь все совсем просто)

Код:

procedure FillTree(Tree T)
{
Очистить дерево T;
Добавить к дереву T корневой узел TreeNode RootTN;
Создать элемент RootNode для корневого узла;
RootNode.NodeID = 0;
RootNode.ParentID = 0;
RootNode.NodeName = что_угодно;
RootNode.NodeType = 1; // корень обязательно должен быть папкой
FillNode(RootNode, RootTN);
}

Правда, алгоритм явно сыроват, я придумал его на лету. Похоже, что корневая вершина отрисуется дважды. Но за основу его взять вполне можно, а детали почистим по ходу.

[Dimyan]

Отчет о проделаной работе
Я привел свою базу к выше описанному виду, сделал добавление "папок" и "файлов" все великолепно добавляется и сохраняется, создал обработку ошибок, чтоб нельзя было создать "папку" или "файл" в "файле". В свойство Tag автоматом заносятся NodeID этого узла (потом просто считываю Tag у родителя и занашу к вновь созданному в  ParentID)
Но вот с загрузкой вместе с рекурсией совсем запутался
Я вроде понял что нужно создать (не прорисовывая в дереве) узел RootNode типа Node. Но по какому принципу добавлять корневой узел TreeNode RootTN?
Ведь нельзя брать из базы первую запись, потому что изначально конечно создается первый корневой узел и онже первый заносится в базы (вроде нет ничего проще плясать от первой записи в базе) но ведь в позледствии работы он может быть удален со и тогда получается что первой записью в базе может оказаться совсем бругой узел. в общем до меня чето плохо доходит с чего начать загрузку

[Alf]

Dimyan, а давай сделаем так.
Раз уж у тебя с базой все наладилось, набей в нее побольше данных и пришли мне файл .mdb, чтобы мне не тратить время на выдумывание данных. А я сделаю тебе процедуру рекурсивного разбора дерева. Мне кажется, что на C# она получится гораздо короче, чем словами рассказывать. Да и нагляднее.
Мой адрес alf63[a]list.ru
P.S. Кстати, у тебя проблемы с рекурсией в данном частном случае, или вообще с ней трудности? Может, в разделе с уроками раскрыть эту тему?

[Dimyan]

Alf,  я был бы бы тебе очень благодарен если бы ты сделал урок по рекурсии. Ситуация такая что я читал о ней но реально встретился впервые, а там где я читал небыло примеров нормальных для сомастоятельного выполнения, да и раздел по рекурсии занимал не болие странички, все сжато
А файл я тебе вечером вышлю, только он как я уже выше говорил выше в формате XML, ведь это стандартный формат сохранения DataSet (DataSet.Write()), я его еще для красоты так сказать со своим расширением сохраняю , но зато можно прочитать даже в блокноте

[Alf]

Dimyan, молодчина, с организацией данных сделал все в лучшем виде. Загрузил твою базу в Access без проблем.
Единственное предложение. Ты в поле NodeType обозначаешь "папку" как 0, а "файл" - как 1. Я предлагаю обозначать "файл" через 0, а "папку" - любым ненулевым значением. В этом случае мы сможем в дальнейшем различать разные категории папок, например, разными иконками. Подумай, может ли это нам как-то пригодиться.
По поводу статьи о рекурсии - вчера начал писать, скоро увидишь ее опубликованной. Думаю, найдешь в ней кое-что полезное для себя.

[Anonymous]

Единственное предложение. Ты в поле NodeType обозначаешь "папку" как 0, а "файл" - как 1. Я предлагаю обозначать "файл" через 0, а "папку" - любым ненулевым значением. В этом случае мы сможем в дальнейшем различать разные категории папок, например, разными иконками. Подумай, может ли это нам как-то пригодиться.

Изменил

По поводу статьи о рекурсии - вчера начал писать, скоро увидишь ее опубликованной. Думаю, найдешь в ней кое-что полезное для себя.

Жду с нетерпением

[Dimyan]

Alf, пока ничего?  :oops:  

[Alf]

Dimyan, терпение... Вчера вечером начал дома, но не успел завершить. Скоро будет.

[Alf]

Dimyan, лови работающий проект в почтовом ящике!
А тут - несколько слов комментария.
Вот так выглядит основная процедура заполнения дерева:

Код:

    private void FillBranch(TreeNode tn)
    {
      // получить список дочерних узлов для tn
      // выбираем из базы данных все вершины, у которых значение поля ParentID
      //  совпадает со значением тега текущего узла tn
      OleDbCommand cmdGetSbl = new OleDbCommand(strSqlCmd, oleDbConnection1);
      OleDbParameter prmParentID = new OleDbParameter("ParentID", OleDbType.Integer, 4);
      cmdGetSbl.Parameters.Add(prmParentID);

      AdditionalInfo tnai = tn.Tag as AdditionalInfo;
      cmdGetSbl.Parameters["ParentID"].Value = tnai.NodeID;
      OleDbDataReader dr = cmdGetSbl.ExecuteReader();

      // строим список узлов
      ArrayList nodeList = new ArrayList();
      while (dr.Read())
      {
        TreeNode stn = new TreeNode();
        AdditionalInfo stnai = new AdditionalInfo();
        stn.Text = dr.GetString(2);
        stnai.NodeID = dr.GetInt32(0);
        stnai.ParentID = dr.GetInt32(1);
        stnai.NodeType = dr.GetInt16(3);
        try
        {
          stnai.AnswerText = dr.GetString(4);
        }
        catch
        {
          stnai.AnswerText = "";
        }
        stn.Tag = stnai;
        nodeList.Add(stn);
      } // while
      dr.Close();

      // добавить все дочерние узлы к текущему
      foreach (TreeNode nn in nodeList)
      {
        tn.Nodes.Add(nn);
        FillBranch(nn);
      } // foreach
    }

Основные идеи:

1. Сначала я думал обращаться к базе данных по каждому щелчку мыши за текстом ответа. Потом решил создать классAdditionalInfo и хранить его вместе с узлом дерева как свойство Tag. В нем хранятся ID узла, ID родителя, тип узла и текст комментария. Не исключено,что эти данные пригодятся тебе в дальнейшей работе.

2. Алгоритм работы процедуры следующий: найти все дочерние узлы для текущего в базе, занести их в список, а затем добавлять каждый узел к текущему дочерним и рекурсивно повторять процедуру для каждого из них.

3. Процедуру можно оптимизировать, если рекурсивные вызовы делать не для каждого узла, а только для директорий.

4. Считывание всех узлов из базы данных - вынужденная мера, поскольку соединение Connection может иметь только один выполняющийся DataReader в данный момент времени. Поэтому приходится считываьт их все разом и освобождать DataReader для следующего рекурсивного вызова.

Проблемы:

TreeView реагирует на клики мыши с запозданием. В причинах пока не разбирался. Возможно, по ходу дела теряет фокус.

[Dimyan]

Alf, большое спасибо, я все получил.
Изменил ConnectionString, все работает.
Теперь буду разбираться с кодом (там много для меня нового).