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

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


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

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

А может сам посмотришь как в 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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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