| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
TreeView из списка Файлов [Delphi, Windows]
QAZ © (2009-05-12 12:38:00)есть несортированый список файлов с путями
имено готовый список, а не поиск по папкам
как по списку построить дерево?
есть решение на VCL http://www.delphisources.ru/pages/faq/base/sl_to_dir_tree.html
помогите пожалуйста перевести в кол
или может есть у кого готовое уже
D[u]fa (2009-05-30 10:36:00) [1]Не согласен.. по скорости среда VB не уступает Delphi. А местами и по удобству рулит, но тем не менее с вб ушел на делфи..
Vladimir Kladov (2009-05-29 23:14:00) [2]любой из них будет при скроле глючить если число строк больше 65535
опрометчиво, listview - хоть миллиард... Только все-таки лучше его делать виртуальным.
в висте и винде7 проблема не устранена
и не будет никогда устранена - для treeview.
> VB в настоящий момент - это полностью 32-разрядный ООП-язык
если вы про .NETНет, я про VB, а не про VB#. Единственный его существенный недостаток - это большая библиотека времени выполнения, не предустановленная в системе, и монстроподобная среда разработки (ms vc++), при том, что она значительно проигрывает delphi по удобству и скорости. А так, разработчиков на западе подавляющее большинство сидят именно на VB.
QAZ (2009-05-29 18:27:00) [3]
> Ну ведь говорили что не рекомендуется)
ну знаеш что, не рекомендуется...
как я написал вся проблемма в скролбаре,а он цепляется автоматом к любому контролу который может скролица
буть то листвиев , листбокс или мемо
и соответствено любой из них будет при скроле глючить если число строк больше 65535
такчто проблем не в дереве а вобще в принципе...
в висте и винде7 проблема не устранена
> VB в настоящий момент - это полностью 32-разрядный ООП-язык
если вы про .NET, то бейсик там уже не язык а просто вариант написания кода также как и сишарп и любой другой который там используется
D[u]fa (2009-05-29 14:18:00) [4]Ну ведь говорили что не рекомендуется)
Vladimir Kladov (2009-05-29 14:18:00) [5]Про VB - это просто пример для воспроизведения. VB в настоящий момент - это полностью 32-разрядный ООП-язык, отличается от C++ практически только синтаксисом и отсутствием асм-вставок. Компилятор слабоват, код не сильно заоптимизирован, но в принципе тех тормозов, что характерны для интерпретируемого Бэйсика древности, давно уже нет.
QAZ (2009-05-29 12:43:00) [6]прикольно
итемы больше 65535 в дерево добавляются вроде без проблем
а вот скролбар который к нему цепляеца не может скролить
больше (позиция у него WORD а макс.значение в DWORD пипец косяк)
скорость добавления падает в 10 раз примерно после 20000 с 1000\сек до 100\сек
эт если в один уровень вбивать,а если ветвиться то сразу 100\сек
это все на пень4 1.6 ггц с учетом processmessages и выводом в заголовок формы
на скорость навигации ничего не влияет
QAZ (2009-05-28 22:11:00) [7]
> http://support.microsoft.com/kb/182231
не катит :) там речь идет о Visual Basic 4.0 и о 16разрядных WORDах (типа максимум 65535)
а современка вся работает на DWORDах
кроме того тормоза в Visual Basic это неудивительно в принципе-ибо тупо скрипт
вот спецально завтра проверю на 100 000 итемах :)
Vladimir Kladov (2009-05-28 20:02:00) [8]http://support.microsoft.com/kb/182231
Хорошо, если точно известно, что число узлов не превысит 10000. Но и то медленно. В моём случае число узлов заведомо может превышать, а тормозов и без treeview хватало, чтобы ещё и здесь ждать считая секунды после каждого клика.
QAZ (2009-05-27 18:47:00) [9]да со скорость все ясно, это изпод делфи тормозит а без него нормально
а по поводу того что не рекомендуется больше 1000 если можно ссылку на микрософт
а то все любят вспоминать рекомендации и ограничения относящиеся к 16битным прогам и виндам типа 9х
однакош прогресс не стоит на месте :)
в мсдн я на такие рекомендации не натыкался , да и дерево мое в 10000 узлов живет и чувствует себя прекрасно,да и с большим числом думаю справица не хуже
Vladimir Kladov (2009-05-27 16:08:00) [10]Все-таки вы не в то место в исходниках аосмтрели, QAZ. Основная разница в том, что VCL для ускорения поиска в дереве испольузет виртуальность (LPSTR_TEXTCALLBACK) и фактически строит свой дубль дерева в оперативной памяти. В итоге для доступа к содержимому узлов он смотрит просто на то, что лежит в памяти. Версия KOL минимальна, в ней все делает система. За каждым узлом надо лезть через функции API, что намного дольше. А смысла развивать эту тему я не вижу. В любом случае, хоть на VCL, хоть где, деревом treeview не рекомендовано пользоваться, если число узлов может быть больше 1000. Для VCL я написал FastTreeView на работе, на базе ListView, и мне там до лампочки, хоть сотни тыщ узлов, все работает в пределах допустимой реакции. Но и кода там прилично получается, на то он и VCL.
QAZ (2009-05-27 13:45:00) [11]незнаю че ты докопался до сортировки
но факт, что по вопросу данной темы
ее влияние отсутствует т.к. IndexOf
в коле реализован также как в вкл
и такимже образом используеца в алгоритме
а список дается уже сортированым
exero (2009-05-27 11:44:00) [12]А может сам посмотришь как в 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 11:34:00) [13]
> Утверждение того что включение/выключение сортировки в VCL никак не > влияет на IndexOf - полный бред
а тыбы посмотрел как устроен IndexOf и понялбы что не влияет
т.к. перебор идет в ЛЮБОМ случае от начала до конца списка и выход при нахождении
и если ты ищеш тот элемент который в сортированом списке
лежит в конце,то он найдется позже чем в несортированом(например находится по середине) LOL.
> проверю точней через пару часов
я фигею, реально тормоз при запуске из под делфи
причом даже при отсутствии отладочной инфы
exero (2009-05-27 09:10:00) [14]FastMM4 стандартное решение позволяющее ускорить работу со строками (результаты в различных случаях отличаются на порядки). Утверждение того что включение/выключение сортировки в VCL никак не влияет на IndexOf - полный бред. В KOL, вроде, преимущества поиска в отсортированном списке строк не используются, точно уже не помню. То что кому-то кажется что алгоритм никак не зависит от сортировки - это не значит что он от нее не зависит LOL.
И еще мне ничего не НАДО, надо тебе, почувствуй разницу.
QAZ (2009-05-27 08:50:00) [15]
> Таки внимательнее надо портировать
ну про сортировку вы зря, ее влияние было проверено сразу
и собствено как отключение ее в ВКЛ так и включение в КОЛ
НИКАК не влияют на процесс и собствено алгоритм написан так
что ему реальньно пофег на нее
> Таки заставили глянуть в сырцы
вот надо было СНАЧАЛА глянуть а потом советовать
> Ставь FastMM4
> а если кол-программу не из дельфи запускать?
мм щас прям так не скажу но вроде без делфи тажа фигня
проверю точней через пару часов
exero (2009-05-27 07:31:00) [16]Таки заставили глянуть в сырцы - "ахринеть какая разница" потому-что ищете в отсортированном списке строк и в VCL при поиске это учитывается... Таки внимательнее надо портировать.
MTsv DN (2009-05-26 23:55:00) [17]Сырцы не смотрел, но раз пошла такая пьянка, то есть PFastStrList, PList...на худой конец свой алго написать...
Дмитрий К (2009-05-26 22:30:00) [18]
> КОЛ-50 секунд,ВКЛ-8.6 секунд,
а если кол-программу не из дельфи запускать?
У меня всего на секунду медленнее выполняется.
QAZ (2009-05-26 21:51:00) [19]
> Vladimir Kladov
НЕНЕ, вы не поняли малость, разница в 6 (шесть) раз !это написано выше
функции максимально (насколько можно) идентичны для кол и вкл (я про FillTreeViewWithFiles)
> Приведенный пример на 10000 элементов на одном уровне не
> показателен.
в том то и дело что почемуто ВКЛу быстрей выполнить FillTreeViewWithFiles
чем просто забить 10000 элементов на один уровень
> Ожидание 20 или 30 секунд закрытия - какая разница?
вот имено что никакой ни при каких условиях: КОЛ-50 секунд,ВКЛ-8.6 секунд, а это АХРИНЕТЬ какая разница
кроме того с учетом того что при простой забивке 10000 элементов на один уровень не большая разница,напрашивается мысль что тормозит не дерево а что то другое... например StrList и\или работа со строками
Vladimir Kladov (2009-05-26 20:53:00) [20]Достаточно посмотреть код из VCL и подумать над ним. Да, в полтора раза быстрее. Но во сколько раз больше? И зачем? treeview с более чем 1000 элементов будет всяко работать настолько медленно, что имеет смысл обойтись без него. Например, изобразить дерево в виртуальном listview. Приведенный пример на 10000 элементов на одном уровне не показателен. Выполните цикл еще раз и потом закройте окно. Ожидание 20 или 30 секунд закрытия - какая разница? Это в любом случае превышает секунду, что есть разумное время ожидания. Не стои свеч, в общем. А KOL предназначен для уменьшения размера приложения.
| |
Страницы: 