Пишу аналог стандартного TreeView, но с новыми возможностями и более быстрой обработкой. На данный момент есть поддержка всех стандартных стилей и сообщений и некоторые навороты. Например: встроенный DragAndDrop с возможностью вставлять между строк, Multiselect, табличный вид(со столбцами), несколько визуальных решений, и из-за чего собственно я начал этим заниматься — поддержка работы с деревом на уровне "пользователя". Тоесть 2 режима работы: 1й это стандартная работа в виде сообщений типа TVM_INSERTITEM, TVM_DELETEITEM и тд... 2й способ заключается в том, что дерево создаете вы сами(структура с указателями на соседние узлы) и лишь даете объекту адресс на него. Способ харошь тем, что в этой структуре вы можете хранить всё, что вам вздумается и выполнять любые алгоритмы с деревом на более низком уровне.
При всём этом грамотная система перерисовки, что скорость её независит от кол-ва узлов(в стандартном дерева прямая зависимость). Намечаю выпустить объект под несколько систем, включая билдер. Я бы хотел услышать с какими на практике трудностями и потребностями сталкиваются люди, когда хотят использовать дерево и я попробую это реализовать.

Здравствуйте, Аноним, Вы писали:

А>При всём этом грамотная система перерисовки, что скорость её независит от кол-ва узлов(в стандартном дерева прямая зависимость).

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

Возможности использования:
1) создание дерева на базе ID & ParentID (дается одноранговый масив объектов, у которых есть такие проперти)
2) создание дерева на базе "пути" (path). часто есть так называемое дерево построенное на базе символа разделителя PathDelimiterChar. так вот хотелось бы давать полный путь а получать ссылочку на объект самый близкий по иерархии.

пример:
+ node1 == full path( node1 )
+ node2 == full path( node1.node2 )
+ node3 == full path( node1.node2.node3 )

по запросу: дай ближайшую ноду get_nearestNode( "node1.node2.node4" ) вернет node2 и можно еще оставшуюся часть пути...

Здравствуйте, alku, Вы писали:

A>если не трудно можно кинуть теорией или ссылочко на алгоритм "граммотной перерисовки"? А то я что-то смутно представляю, как можно вне зависимости от количества узлов в дереве определять позиции... хотелось бы просветиться...

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, alku, Вы писали:

A>>если не трудно можно кинуть теорией или ссылочко на алгоритм "граммотной перерисовки"? А то я что-то смутно представляю, как можно вне зависимости от количества узлов в дереве определять позиции... хотелось бы просветиться...

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

а как быть с случаем когда надо по точке найти ноду? (размер клиентской области 10000 по высоте и такое бывает... )

Здравствуйте, alku, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, alku, Вы писали:

A>>>если не трудно можно кинуть теорией или ссылочко на алгоритм "граммотной перерисовки"? А то я что-то смутно представляю, как можно вне зависимости от количества узлов в дереве определять позиции... хотелось бы просветиться...

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

A>а как быть с случаем когда надо по точке найти ноду? (размер клиентской области 10000 по высоте и такое бывает... )

Бред. Кому нужна такая область. Если у людей хватило на монитор с таким разрешением, то им хватит и на всё остальное . А HitTest просчитывается тоже только на видимой области. Подругому просто быть неможет .

А>Пишу аналог стандартного TreeView [skip]

Прошу прощения, но по описанию — вы пишете аналог VirtualTreeview
http://www.delphi-gems.com/VirtualTreeview/

Здравствуйте, oles_volvo, Вы писали:

А>>Пишу аналог стандартного TreeView [skip]

_>Прошу прощения, но по описанию — вы пишете аналог VirtualTreeview
_>http://www.delphi-gems.com/VirtualTreeview/

VirtualTreeView искулючительно под дельфи. На других системах(кроме .NET) ничего подобного нет. Я же затачиваю его под все основные среды. Под некоторые в их формате объектов, а вообще это универсальный Dll файл, который может быть подгружен чем угодно.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, alku, Вы писали:

A>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте, alku, Вы писали:

попробуем с другой стороны: операция скрола. Юзеру надо чтобы контрол показал ноду, которая будет в виртуальных координатах распологаться в точке x,y = ( 10, 100000 ). Как вы решили такой случай?

Здравствуйте, alku, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, alku, Вы писали:

A>>>Здравствуйте, Аноним, Вы писали:

А>>>>Здравствуйте, alku, Вы писали:

A>попробуем с другой стороны: операция скрола. Юзеру надо чтобы контрол показал ноду, которая будет в виртуальных координатах распологаться в точке x,y = ( 10, 100000 ). Как вы решили такой случай?

Это один из редких случаев, когда приходиться пройти по всему дереву(видимому). Но ведь это не перерисовка, никаких уродливых морганий, как в стандартном не будет. В случае с родными сообщениями скролл бара опятьже этого не требуется.

Здравствуйте, <Аноним>, Вы писали:

А>…Например: встроенный DragAndDrop …
А>Я бы хотел услышать с какими на практике трудностями и потребностями сталкиваются люди, когда хотят использовать дерево и я попробую это реализовать.

Как решил проблему перетаскивания в таком вот примере:

Root
|
+-Child1
| |
| +-SubChild11
|
+-Child2
|
+-Child3

Пользователь "захватил" Child3 и отпустил между Child2 и SubChild11. Куда вставить результат? В конец дочерних узлов Child1 (после SubChild11) или в корень, перед Child2?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, alku, Вы писали:

A>>Здравствуйте, Аноним, Вы писали:

A>>попробуем с другой стороны: операция скрола. Юзеру надо чтобы контрол показал ноду, которая будет в виртуальных координатах распологаться в точке x,y = ( 10, 100000 ). Как вы решили такой случай?

А>Это один из редких случаев, когда приходиться пройти по всему дереву(видимому). Но ведь это не перерисовка, никаких уродливых морганий, как в стандартном не будет. В случае с родными сообщениями скролл бара опятьже этого не требуется.

жаль это как раз наиболее интересный случай для таких контролов. если получается что у нас в дереве много элеметов, 1 милион например, то чтобы найти позицию для скрола понадобиться перебрать последовательно (NextSibling, NextVisibleNode) список нод, а в нем прямая зависимость, чем больше нод может быть Visible тем больше времени нам надо на поиск ноды...

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

good luck

Здравствуйте, alku, Вы писали:

A>жаль это как раз наиболее интересный случай для таких контролов. если получается что у нас в дереве много элеметов, 1 милион например, то чтобы найти позицию для скрола понадобиться перебрать последовательно (NextSibling, NextVisibleNode) список нод, а в нем прямая зависимость, чем больше нод может быть Visible тем больше времени нам надо на поиск ноды...

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

A>good luck

Ну вопервых с помощью своих рекурсий и сообщений это и правда очень долго. В моём варианте можно держать дерево у себя. Это довольно хлопотно, т.к. многие ф-ции для работы с деревом придется реализовать самому, но например сравните скорость работы сообщения NextItem и передачу адресса указателю tmpnode=tmpnode.next;, да и ещё можно без дурацких рекурсий.
Если же вас и это не устраивает идите от простого. Предположим все узлы одинакового размера, следовательно позиция скролла на 10001м видимом узле будет 10001*высоту узла. Если же размеры различны, находим среднюю величину узла и отталкиваемся от неё. Достаточно просто вести учет кол-ва видимых узлов, которое меняется лишь в 2-3х случаях. Одно ясно точно, что перебирать миллион узлов вас никто не заставляет.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, <Аноним>, Вы писали:

А>>…Например: встроенный DragAndDrop …
А>>Я бы хотел услышать с какими на практике трудностями и потребностями сталкиваются люди, когда хотят использовать дерево и я попробую это реализовать.

_FR>Как решил проблему перетаскивания в таком вот примере:
_FR>

_FR>Root
_FR>|
_FR>+-Child1
_FR>| |
_FR>| +-SubChild11
_FR>|
_FR>+-Child2
_FR>|
_FR>+-Child3
_FR>

_FR>Пользователь "захватил" Child3 и отпустил между Child2 и SubChild11. Куда вставить результат? В конец дочерних узлов Child1 (после SubChild11) или в корень, перед Child2?

После SubChild11. Это самое очевидное, т.к. в обратном случае, если много "сынков" сложно понять куда вставится узел. Вообще над ДаД'ом много посидел, работает очень красиво, под стиль ListView с его разделительными маркерами(хвастаюсь )

Здравствуйте, <Аноним>, Вы писали:

А>После SubChild11. Это самое очевидное, т.к. в обратном случае, если много "сынков" сложно понять куда вставится узел. Вообще над ДаД'ом много посидел, работает очень красиво, под стиль ListView с его разделительными маркерами(хвастаюсь )

А как вставить элемент между Child1 и Child2? Закрыв Child1?

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, <Аноним>, Вы писали:

А>>После SubChild11. Это самое очевидное, т.к. в обратном случае, если много "сынков" сложно понять куда вставится узел. Вообще над ДаД'ом много посидел, работает очень красиво, под стиль ListView с его разделительными маркерами(хвастаюсь )

_FR>А как вставить элемент между Child1 и Child2? Закрыв Child1?

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


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

Здравствуйте, <Аноним>, Вы писали:
А>VirtualTreeView искулючительно под дельфи. На других системах(кроме .NET) ничего подобного нет. Я же затачиваю его под все основные среды. Под некоторые в их формате объектов, а вообще это универсальный Dll файл, который может быть подгружен чем угодно.
Это тебе просто к тому, что надо изучить. Автор VirtualTreeView с математической точки зрения проделал огромную работу по обобщению стандартного TreeView без потери производительности. Само по себе желание написать такой контрол весьма похвально, но оно требует в основном алгоритмических инвестиций, часть из которых уже сделана в VTV.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:
А>>VirtualTreeView искулючительно под дельфи. На других системах(кроме .NET) ничего подобного нет. Я же затачиваю его под все основные среды. Под некоторые в их формате объектов, а вообще это универсальный Dll файл, который может быть подгружен чем угодно.
S>Это тебе просто к тому, что надо изучить. Автор VirtualTreeView с математической точки зрения проделал огромную работу по обобщению стандартного TreeView без потери производительности. Само по себе желание написать такой контрол весьма похвально, но оно требует в основном алгоритмических инвестиций, часть из которых уже сделана в VTV.

Предпочитаю сам поломать голову, да и интересно это. На данный момент добавить 10000 узлов путем TVM_INSERTITEM в моё дерево занимает 110 миллисекунд, в VTV 480, а в "шедевр" всех времен от "коллег" из мелкомягкого — 8362...

Здравствуйте, <Аноним>, Вы писали:

А>Предпочитаю сам поломать голову, да и интересно это. На данный момент добавить 10000 узлов путем TVM_INSERTITEM в моё дерево занимает 110 миллисекунд, в VTV 480 …

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

На codeproject.com advanced treeview смотрел? может, лучше заняться его дописыванием?

Здравствуйте, Ник, Вы писали:

Ник>На codeproject.com advanced treeview смотрел? может, лучше заняться его дописыванием?

Совершенно разные вещи.