Назрела насущная необходимость в многоколончатом treeview. Кто что использует для этого? Может кто нить посоветует готовый контрол? Облазил полинтернета не могу найти ничего подходящего.

Хорошая штука. НО дороговато все же.

ВладимирМБесплатных вы не найдете (если только ломаные). Просто потому, что на практике это почти бесполезная вещь. Как и дерево вообще. Поигрался и бросил. Она красиво выглядит, но работать с ней трудно. Трудно для пользователя. Особенно, если много узлов.

Как правило, делают все-таки два объекта: оглавление (TreeView) и содержание (Grid). Причем содержание можно делать на базе PageFrame, чтобы можно было динамически менять структуру Grid в зависимости от типа узла или уровня вложенности. Отдельные Grid на каждой странице PageFrame и активизация страниц по необходимости.

Возможно, если вы опишите задачу, для решения которой, как вам кажется, нужен именно многоколоночный Grid, вам подскажут можно ли решить задачу другими способами.

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

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

Также не следует спрашивать у опытных пользователей, давно работающих с вашей системой. У них те же проблемы. "Глаз замылился".

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

Главный недостаток работы с деревом - сложность поиска нужных данных. Вы вынуждены создавать паралельную, дублирующую, систему навигации и поиска. Т.е. смотрим "картинку" TreeView, но реальная работа происходит в "плоских" таблицах и списках.

И возникает вопрос: а зачем этот TreeView вообще нужен, если основная работа происходит вне этого объекта? Даже та работа, для которой он вроде бы и создавался - облегчение поиска и навигации. Не облегчает TreeView ни поиска, ни навигации. Только усложняет.

Мы занимаемся разработкой пользовательских интерфейсов уже лет 15 и почти всеэто время в фокспро, начиная с 2.0. За это время было перепробовано много всего. в результате проб и ошибок наработано определенное количество классов в приемов построения интерфейсов. Назови мне такое приложение, где бы использовались ПЛОСКИЕ справочники. У нас специфика такова что ВСЕ справочники имеют древовидную структуру (то есть, побиты на группы, причем уровень вложенности групп может быть очень разный). Теперь подскажи мне способ отображать древовидные структуры лучше, чем это делает тривью. Что касается поиска, то, по моему, я говорил - поиск интергрирован прямо в класс,которому передается таблица определенной структуры. Поиск контекстный и очень быстрый. Если Вы считаете, что тривью не ускоряет ни навигации ни поиска, то я, исходя из своего опыта, считаю обратное. И не только я. Сейчас нет ни одной крупной программы, которая могла бы обойтись без тривью.
А вообще разговор не о том. Мне нужен определенный контрол и я знаю КАК и ЗАЧЕМ его использовать. ВОпрос стоит, что либо разрабатывать его самостоятельно, либо использовать что-то, что уже кто-то разработал. но то, что он нужен и я буду его использовать у меня сомнений нет.
Кстати, если интересно классом могу поделиться. Правда не уверен, что выберу время чтобы хорошенько его задокументировать, тем более что там используется несколько классов, каждый из которых может быть использован самостоятельно.

Владимир, я ОЧЕНЬ попрошу вас, не вести разговор в таком ключе. Мы все здесь всказываем свои мнения и пришли на форум не для того чтобы нас УЧИЛИ как жить дальше и указывали на наши недостатки, а для обсуждения неких вопросов. Если кроме психологии (ну там привыкли и все аткое) других аргументов нет, то наверное эти лучше опустить. ТЕперь по порядку.

ВладимирМ Gendrive

Вы настолько привыкли использовать TreeView, что просто не видите других способов организации данных.

Тривью мы используем всего пару лет. Просто до этого, так же как и у большинства кто здесь пишет, руки не доходили толком разобраться в его функциональности и приемах работы с ним. Часто можно слышать упреки тривью в том что он медленно заполняется например. В моем классе ПОЛНОЕ заполнение тривью с порядка 10000 узлов происходит 2-3 секунды. причем это стандартный тривью.

ВладимирМ
Есть запись, у нее есть реквизиты (поля). Например, признак группы. Хотите "дерево"? Добавьте еще один реквизит (поле) - подгруппа. И какие проблемы вывести это как линейный список? Это один из вариантов. Можно еще использовать связанные таблицы (один уровень - одна таблица). Есть и другие варианты. Более того, есть другие принципы организации работы.


Отобразить плоские данные в тривью без проблем. А вот попробуй сделать обратное в гриде. Потому то я и ищу контрол, который бы объединял функциональность грида и тривью. Ибо в нем я могу отображать и плоскую структуру и древовидную.

ВладимирМ
Неопределенное количество уровней вложенности - это либо ошибка проектирования, либо специфическая область деятельности. Да и то, во втором случае, использование TreeView, как правило, служит не для поиска, а для наглядного представления некой отдельной (небольшой) структуры.


Мне кажется, что тебе нужно отучаться говорить категорично. Простой пример - справочник материалов. Ну ка запроектируй его мне с ОПРЕДЕЛЕННЫМ количеством уровней вложенности? Или справочник проектов и работ. Ты когда нить видел Primavera например?

ВладимирМ
TreeView для поиска не приспособлен. Он вообще этого не умеет. Никак. Классический пример - проводник Windows. Иерархия директорий, каталогов, папок.


Если ТЫ не умеешь этого делать, то не значит что этого не может делать никто.

ВладимирМ
Вы сели за чужой компьютер. Вы не знаете где именно, в какой папке, находится нужный вам файл. Как вы будете осуществлять поиск с помощью дерева? Очевидно, просто тупо открывая ВСЕ ветки. Т.е. вообще ВСЕ. У вас нет других вариантов. Какое уж тут ускорение...


а рядышком нажать копочку поиск религия не позволяет?

ВладимирМ
А как же поиск? А поиск файла, осуществляется в линейном списке! Результат поиска - это линейный список БЕЗ дерева.

Другими словами, поиск осуществляется ВНЕ идеологии древовидной струкутры. И только ПОСЛЕ окончания поиска вы делаете обратное преобразование. На основании найденной информации достраиваете иерархию.


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

ВладимирМ
Получается двойное преобразование - из дерева в линейный список, затем поиск в этом линейном списке, затем преобразование результата в дерево. И зачем тут вообще нужно дерево? Почему бы не выбросить этот явно лишний элемент?


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

ВладимирМ
Впрочем, вы уже не в состоянии сделать что-то другое. Вам мешает наработанный FrameWork. Теперь уже не вы разрабатываете интерфейс, а созданный FrameWork диктует вам принципы работы. Вы вынуждены подстраиваться под существующую систему и ее интерфейс. Без вариантов.

Собственно, поэтому можете не обращать внимание на все ранее сказанное. Даже если вы и захотите, вы не сможете это все применить на практике. Созданный FrameWork не позволит.

Еще раз. отучаемся говорить категорично и пытаться оценивать других пользуясь своим опытом. Если ты НЕ НАУЧИЛСЯ использовать что-то, то это совсем не значит что это использовать невозможно и вредно. Есть волшебное слово "ИМХО" . Есть различные мнения и от того что оно твое оно вовсе не становится истиной в последней инстанции.

Валентин Н.Карелин,

Насчет скорости заполнения. Да она оставляет желать лучшего. Но, попробуй перед заполнением сделать тривью visible = .F. удивишься насколько возрастет скорость заполнения. ВО всяком случае работа в пределах первого дестяка тысяч узлов вполне себе комфортна.

AleksMedGendrive,
милости просим, FoxClub , делитесь, а практика и время вас/нас рассудят.

постараюсь создать краткое описание классов и выложить.

Валентин Н.Карелин,

в результате экспериментов я выяснил, что даже если форма не отображается, но у тривью визибл стоит .Т. то оно все равно пытается заниматься визуальной перерисовкой. А вот если ему выключить видимость, то скорость возрастает в разы. попробуй.
По поводу баз данных. У нас все процедуры на SQL заточены под то, чтобы СРАЗУ выдавать таблицу с определенной структурой. В частности, в ней обязаны быть поля ID, Parent_ID, Descr. Есть еще опциональные поля в таблице: isFolder, Color_ID, Icon_ID еще какие то. классу передается только эта таблица и уже на базе ее он сам строит деерво со всеми рюшечками. Поиск тоже внутри класса - ищет сразу внутри таблицы и отбражает в дереве. То есть, я думаю, тебе подготовку данных нужно осуществлять ДО ТОГО как ты начнешь строить дерево.

Валентин Н.Карелин,

щас лишний раз проверил. Запуск скомпилированного приложения (справочник материалов) от момента запуска EXE до отображения окна с получением данныс с SQL (причем не просто получение а выборка их там из еще большего справочника (1сv8 SQL) и обработкой их там и заполнением тривью, количество нодов чуть меньше 4 с половиной тысяч (точно - 4440 узлов) занимает около 5 секунд. Как это выглядит видно на приложенном файле. причем вся эта форма по сути один класс просто брошенный на форму.

Aleksey-K
Но вот какая штука получилась.. Для ввода данных в справочник (операция не очень частая, согласитесь) иерархия помогает. Модно не торопясь найти нужную группу элемента и добавить в нее новый элемент. Но вот когда операционист использует такой справочник для выбора нужного элемента при оформлении документа (например, приходный ордер), то оказалось, что ему (операционисту) удобнее (т.к. значительно быстрее) иметь общий список всех элементов справочника в виде грида и хорошее средство для поиска (отбора) нужного элемента в этом гриде. Наблюдения показали, что опытный операционист НИКОГДА не использует, сначала выбор в "дереве" нужной группы в иерархии элементов, а потом, сам поиск элемента. Он ПОМНИТ ключевые параметры нужно элемента (название, код и пр.) и использует их для поиска в "плоском" гриде. Нам в системе даже пришлось добавить на формы выбора элементов справочника опцию ("искать в подгруппах"), которая выводит в гриде элементы ВСЕХ подуровней "дерева", т.е., фактически, отключает "дерево" и выводит в грид ВСЕ элементы справочника, а не только из выбранной ветке.


Алексей, точно такой же режим поиска у меня реализован в тривью. Человек набирает часть название, а контрол отображает ему то, что подходит под то что он ввел, одновременно раскрывая необходимые группы. ПРичем установкой одной галочки поиск может осуществляться как с начала строки, так и внутри строки. Также пожно ввести строку поиска и отобразить ТОЛЬКО ТО что подходит под критерии поиска (ну например набираешь слово компрессор а он может находиться в разных группах и быть разных типов компрессоры). Так что это все просто вопрос реализации.

Aleksey-K,
я вот решил показать скриншот как это работает
В правом верхнем углу - поле поиска. Если убрать галку "показывать только найденное" то идет поиск в реальном времени когда набираешь слово. Если ее поставить появляется кнопочка поиска нажимая которрую получаешь в тривью все записи подходящие под условие. Они подсвечены зеленым.