TreeView из списка Файлов

← →
QAZ (2009-05-12 12:38) [0]

есть несортированый список файлов с путями
имено готовый список, а не поиск по папкам
как по списку построить дерево?
есть решение на VCL http://www.delphisources.ru/pages/faq/base/sl_to_dir_tree.html
помогите пожалуйста перевести в кол
или может есть у кого готовое уже

← →
Дмитрий К © (2009-05-12 19:33) [1]

program Project1; uses KOL; procedure FillTVWithFL(TV: PControl; FL: PStrList); function ItemIndex(Parent: Cardinal; ItemName: string): Cardinal; var Item: Cardinal; begin Result := 0; Item := TV.TVItemChild[Parent]; while Item <> 0 do begin if AnsiCompareStrNoCase(TV.TVItemText[Item], ItemName) = 0 then begin Result := Item; Break; end; Item := TV.TVItemNext[Item]; end; end; var i: Integer; s, s1: string; Parent, Item: Cardinal; begin for i := 0 to FL.Count - 1 do begin s := FL.Items[i]; s1 := Parse(s, "\"); Parent := TVI_ROOT; while s1 <> "" do begin Item := ItemIndex(Parent, s1); if Item = 0 then Parent := TV.TVInsert(Parent, TVI_SORT, s1) else Parent := Item; s1 := Parse(s, "\"); end; end; end; var Form, TV: PControl; SL: PStrList; begin Form := NewForm(nil, "TV"); TV := NewTreeView(Form, [], nil, nil).SetAlign(caLeft); SL := NewStrList; SL.Add("D:\Program Files\Borland\Delphi6\Source\Vcl\Printers.dcu"); SL.Add("D:\Program Files\Borland\Delphi6\Source\Vcl\WinHelp.dcu"); SL.Add("C:\WINNTS\system\BORLNDMM.DLL"); FillTVWithFL(TV, SL); SL.Free; Run(Form); end.

← →
QAZ (2009-05-13 12:11) [2]

пасиба

← →
QAZ (2009-05-22 11:11) [3]

хм а ВКЛьный вариант в 6 раз быстрее !!! 8,6 секунд против 50 при списке из 10000 файлов
так что зря Дмитрий К исключил CachedStrs из алгоритма :(

← →
QAZ (2009-05-25 10:46) [4]

не знаю точтоли я перевел ВКЛьный вариант с CachedStrs, тем не менее работает ,но скорость всего лиш 36 против 50
походу в даном случае CachedStrs особо не при делах,а просто
ВКЛ имеет по полной КОЛ в плане скорости

procedure FillTreeViewWithFiles(TreeView1: PControl; Strs: PStrListEX); var CachedStrs: PStrListEX; // CachedStrs procedure AddItem(Lev: Integer; ParentNode: Cardinal; S: string); function FindNodeWithText(AParent: Cardinal; const S: string): Cardinal; var K: Integer; fStr: string; tmpNode: Cardinal; begin Result := 0; fStr := S + Int2Str(AParent); K := CachedStrs.IndexOf(fStr); if K > -1 then Result := CachedStrs.Objects[K] else begin if AParent <> 0 then tmpNode := TreeView1.TVItemChild[AParent] else tmpNode := TreeView1.TVRoot; while tmpNode <> 0 do begin if TreeView1.TVItemText[tmpNode] = S then begin Result := tmpNode; CachedStrs.AddObject(fStr, tmpNode); break; end; tmpNode := TreeView1.TVItemNext[tmpNode]; end; end end; var prefix: string; ID: Integer; aNode: Cardinal; begin if S = "" then Exit; ID := Pos("\", S); prefix := ""; if ID > 0 then prefix := Copy(S, 1, ID - 1) else begin prefix := S; S := ""; end; aNode := FindNodeWithText(ParentNode, prefix); if aNode = 0 then begin aNode := TreeView1.TVInsert(ParentNode,TVI_LAST,prefix); end; AddItem(Lev + 1, aNode, Copy(S, ID + 1, Length(S))); end; var K: Integer; begin CachedStrs := NewStrListEx; try for K := 0 to Strs.Count - 1 do AddItem(0, 0, Strs.Items[K]); finally CachedStrs.Free; end; end;

← →
QAZ (2009-05-25 11:32) [5]

хм простая конструкция типа
procedure TForm1.Button2Click(Sender: TObject); var i: Integer; debug:cardinal; begin debug:=gettickcount; for i := 0 to 10000 do begin TV.Items.AddChild(nil,"Item" + InttoStr( i )); //TV.TVInsert( 0, 0, "Item" + Int2Str( i ) ); end; form1.Caption:=inttostr(gettickcount-debug); //form.Caption:=int2str(gettickcount-debug); end;

показывает
КОЛ=13672 мс
ВКЛ=11265 мс
что просто работа с деревом "почти" одинакова
тогда где тормоз который дает 6 кратный разнос ???

← →
QAZ (2009-05-25 11:38) [6]

кстати !!! а какова? просто добавление итемов у ВКЛ медленей чем ВКЛьная версия FillTreeViewWithFiles ???

← →
exero (2009-05-25 11:39) [7]

Ставь FastMM4 и будут пузомерки работать примерно одинаково.

← →
QAZ (2009-05-26 10:48) [8]

> Ставь FastMM4

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

← →
exero (2009-05-26 11:14) [9]

"Вам шашечки или ехать?"

← →
QAZ (2009-05-26 17:17) [10]

> "Вам шашечки или ехать?"

переведи

← →
exero (2009-05-26 18:03) [11]

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

← →
QAZ (2009-05-26 19:01) [12]

спасибо, не помогло :)

← →
Vladimir Kladov © (2009-05-26 20:53) [13]

Достаточно посмотреть код из VCL и подумать над ним. Да, в полтора раза быстрее. Но во сколько раз больше? И зачем? treeview с более чем 1000 элементов будет всяко работать настолько медленно, что имеет смысл обойтись без него. Например, изобразить дерево в виртуальном listview. Приведенный пример на 10000 элементов на одном уровне не показателен. Выполните цикл еще раз и потом закройте окно. Ожидание 20 или 30 секунд закрытия - какая разница? Это в любом случае превышает секунду, что есть разумное время ожидания. Не стои свеч, в общем. А KOL предназначен для уменьшения размера приложения.

← →
QAZ (2009-05-26 21:51) [14]

> Vladimir Kladov

НЕНЕ, вы не поняли малость, разница в 6 (шесть) раз !это написано выше
функции максимально (насколько можно) идентичны для кол и вкл (я про FillTreeViewWithFiles)

> Приведенный пример на 10000 элементов на одном уровне не
> показателен.

в том то и дело что почемуто ВКЛу быстрей выполнить FillTreeViewWithFiles
чем просто забить 10000 элементов на один уровень

> Ожидание 20 или 30 секунд закрытия - какая разница?

вот имено что никакой ни при каких условиях: КОЛ-50 секунд,ВКЛ-8.6 секунд, а это АХРИНЕТЬ какая разница

кроме того с учетом того что при простой забивке 10000 элементов на один уровень не большая разница,напрашивается мысль что тормозит не дерево а что то другое... например StrList и\или работа со строками

← →
Дмитрий К © (2009-05-26 22:30) [15]

> КОЛ-50 секунд,ВКЛ-8.6 секунд,

а если кол-программу не из дельфи запускать?
У меня всего на секунду медленнее выполняется.

← →
MTsv DN (2009-05-26 23:55) [16]

Сырцы не смотрел, но раз пошла такая пьянка, то есть PFastStrList, PList...на худой конец свой алго написать...

← →
exero (2009-05-27 07:31) [17]

Таки заставили глянуть в сырцы - "ахринеть какая разница" потому-что ищете в отсортированном списке строк и в VCL при поиске это учитывается... Таки внимательнее надо портировать.

← →
QAZ (2009-05-27 08:50) [18]

> Таки внимательнее надо портировать

ну про сортировку вы зря, ее влияние было проверено сразу
и собствено как отключение ее в ВКЛ так и включение в КОЛ
НИКАК не влияют на процесс и собствено алгоритм написан так
что ему реальньно пофег на нее

> Таки заставили глянуть в сырцы

вот надо было СНАЧАЛА глянуть а потом советовать

> Ставь FastMM4

> а если кол-программу не из дельфи запускать?

мм щас прям так не скажу но вроде без делфи тажа фигня
проверю точней через пару часов

← →
exero (2009-05-27 09:10) [19]

FastMM4 стандартное решение позволяющее ускорить работу со строками (результаты в различных случаях отличаются на порядки). Утверждение того что включение/выключение сортировки в VCL никак не влияет на IndexOf - полный бред. В KOL, вроде, преимущества поиска в отсортированном списке строк не используются, точно уже не помню. То что кому-то кажется что алгоритм никак не зависит от сортировки - это не значит что он от нее не зависит LOL.

И еще мне ничего не НАДО, надо тебе, почувствуй разницу.

← →
QAZ (2009-05-27 11:34) [20]

> Утверждение того что включение/выключение сортировки в VCL никак не > влияет на IndexOf - полный бред

а тыбы посмотрел как устроен IndexOf и понялбы что не влияет
т.к. перебор идет в ЛЮБОМ случае от начала до конца списка и выход при нахождении
и если ты ищеш тот элемент который в сортированом списке
лежит в конце,то он найдется позже чем в несортированом(например находится по середине) LOL.

> проверю точней через пару часов

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

← →
exero (2009-05-27 11:44) [21]

А может сам посмотришь как в VCL реализовано - файлик Classes.pas - ищем - и всматриваемся до просветления:
function TStringList.IndexOf(const S: string): Integer;
begin
if not Sorted then Result := inherited IndexOf(S) else
if not Find(S, Result) then Result := -1;
end;

← →
QAZ (2009-05-27 13:45) [22]

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

Все-таки вы не в то место в исходниках аосмтрели, QAZ. Основная разница в том, что VCL для ускорения поиска в дереве испольузет виртуальность (LPSTR_TEXTCALLBACK) и фактически строит свой дубль дерева в оперативной памяти. В итоге для доступа к содержимому узлов он смотрит просто на то, что лежит в памяти. Версия KOL минимальна, в ней все делает система. За каждым узлом надо лезть через функции API, что намного дольше. А смысла развивать эту тему я не вижу. В любом случае, хоть на VCL, хоть где, деревом treeview не рекомендовано пользоваться, если число узлов может быть больше 1000. Для VCL я написал FastTreeView на работе, на базе ListView, и мне там до лампочки, хоть сотни тыщ узлов, все работает в пределах допустимой реакции. Но и кода там прилично получается, на то он и VCL.

← →
QAZ (2009-05-27 18:47) [24]

да со скорость все ясно, это изпод делфи тормозит а без него нормально

а по поводу того что не рекомендуется больше 1000 если можно ссылку на микрософт
а то все любят вспоминать рекомендации и ограничения относящиеся к 16битным прогам и виндам типа 9х
однакош прогресс не стоит на месте :)
в мсдн я на такие рекомендации не натыкался , да и дерево мое в 10000 узлов живет и чувствует себя прекрасно,да и с большим числом думаю справица не хуже

http://support.microsoft.com/kb/182231
Хорошо, если точно известно, что число узлов не превысит 10000. Но и то медленно. В моём случае число узлов заведомо может превышать, а тормозов и без treeview хватало, чтобы ещё и здесь ждать считая секунды после каждого клика.

← →
QAZ (2009-05-28 22:11) [26]

> http://support.microsoft.com/kb/182231

не катит :) там речь идет о Visual Basic 4.0 и о 16разрядных WORDах (типа максимум 65535)
а современка вся работает на DWORDах
кроме того тормоза в Visual Basic это неудивительно в принципе-ибо тупо скрипт

вот спецально завтра проверю на 100 000 итемах :)

← →
QAZ (2009-05-29 12:43) [27]

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

скорость добавления падает в 10 раз примерно после 20000 с 1000\сек до 100\сек
эт если в один уровень вбивать,а если ветвиться то сразу 100\сек
это все на пень4 1.6 ггц с учетом processmessages и выводом в заголовок формы

на скорость навигации ничего не влияет

Про VB - это просто пример для воспроизведения. VB в настоящий момент - это полностью 32-разрядный ООП-язык, отличается от C++ практически только синтаксисом и отсутствием асм-вставок. Компилятор слабоват, код не сильно заоптимизирован, но в принципе тех тормозов, что характерны для интерпретируемого Бэйсика древности, давно уже нет.

← →
D[u]fa (2009-05-29 14:18) [29]

Ну ведь говорили что не рекомендуется)

← →
QAZ (2009-05-29 18:27) [30]

> Ну ведь говорили что не рекомендуется)

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

такчто проблем не в дереве а вобще в принципе...
в висте и винде7 проблема не устранена

> VB в настоящий момент - это полностью 32-разрядный ООП-язык

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

любой из них будет при скроле глючить если число строк больше 65535
опрометчиво, listview - хоть миллиард... Только все-таки лучше его делать виртуальным.

в висте и винде7 проблема не устранена
и не будет никогда устранена - для treeview.

> VB в настоящий момент - это полностью 32-разрядный ООП-язык

если вы про .NET Нет, я про VB, а не про VB#. Единственный его существенный недостаток - это большая библиотека времени выполнения, не предустановленная в системе, и монстроподобная среда разработки (ms vc++), при том, что она значительно проигрывает delphi по удобству и скорости. А так, разработчиков на западе подавляющее большинство сидят именно на VB.

← →
D[u]fa (2009-05-30 10:36) [32]

Не согласен.. по скорости среда VB не уступает Delphi. А местами и по удобству рулит, но тем не менее с вб ушел на делфи..

TreeView из списка Файлов Найти похожие ветки