FindFirst и все все все =)

← →
Zion © (2002-09-16 15:09) [0]

Люди, кто знает, есть ли функция более быстрая чем FindXXX или можен нужен более быстрый алгорритм, я незнаю, но тот чтоя писал работает оч. медленно. Он просто все фалы в дириктории (и в поддериктории) добавляет в TLISTBox. Поиск по подкаталогам я оформил в виде рекурсии (как ни странно =))... вот.. но все работает оч. медленно... незнаю даже почему

← →
Song © (2002-09-16 15:46) [1]

Использовать теже самые ф-ии но АПИшные.

← →
McSimm © (2002-09-16 15:49) [2]

Неплохо бы убедиться в оптимальности алгоритма.

← →
REA (2002-09-16 16:53) [3]

А ListBox блокируешь?

← →
Zion © (2002-09-16 18:28) [4]

2 rea
Нет.... чесно говоря даже неподозреваю о чем это =)
McSimm
2 Song
И как это сделать?

← →
Eugene © (2002-09-17 07:31) [5]

А ведь на самом деле вопрос интересный.
Я еще года три назад пытался написать что-то типа NC под винды и столкнулся с такой проблемой: директория, сожержащая более 1000 файлов обрабатывалась более 2 секунд, к примеру DN открывал туже директорию мнгновенно. Возможно тормозит не метод а компонент TListView. В общем тогда я решения этой проблемы не нашел, правда нашел в сети аналог того, чего мне не хватало, поэтому проект закрыл, а вот вопрос остался, причем видимо не только у меня.

← →
Song © (2002-09-17 09:14) [6]

DN использует свои собственные ф-ии из BIOS, а не функции из io.sys как NC. Как следствие, DN и предлагет прямой достп к диску, что дало возможность использования в нём замечательной утилитки - реаниматора.

← →
McSimm © (2002-09-17 11:34) [7]

ListBox.Items.BeginUpdate;
// рекурсия
ListBox.Items.EndUpdate;

← →
Zion © (2002-09-17 14:18) [8]

MCSimm
Спасибо.
Song

← →
Zion © (2002-09-17 14:19) [9]

MCSimm
Спасибо.
Сонг:
Да, и что это за функции? А линные имена поддерживают? =)

← →
Zion © (2002-09-17 14:40) [10]

Вот кстати сам алгоритм:

procedure TForm1.FindFIles(S:string);
var
Sr:TSEARCHREC;

begin
if not DirectoryExists(s) then exit;

findFIRST(s+"\"+frmAddPath.Edit2.Text ,faAnyFile,sr);

repeat

application.ProcessMessages;

frmAddPath.Label2.caption:=inttostr(frmADDPath.ListBox1.Items.Count);
if (sr.name="..") or (sr.name=".") then continue;

if not (DirectoryExists(s+"\"+sr.name)) then
frmAddPath.listbox1.Items.BeginUpdate;
frmAddPath.listbox1.Items.add(StringReplace(s+"\"+sr.name,"\\","\",[rfReplaceAll]));
frmAddPath.listbox1.Items.EndUpdate;
if (DirectoryExists(s+"\"+sr.name)) then FindFiles(s+"\"+sr.Name);

until (FindNeXT(sr)<>0) or (frmAddPath.Button2.Caption="Найти");

← →
Shaman_Naydak © (2002-09-17 15:04) [11]

Родной, ну что ты написал.. сам хоть подумал?
Лочить листбокс надо до 1-го вызова FindFiles и отпускать после отработки
Жуткий текст.. нет FindCLose, не проверяется результат FindFirst, а используется DirectoryExists.. нет try-finally

Мда, батенька, тут надо трудиться и трудиться

← →
McSimm © (2002-09-17 15:05) [12]

Не так.

BeginUpdate / EndUpdate надо окружать множественные изменения, а не одно. Иначе нет смысла (кстати, begin .. end после then забыл?)
Поэтому BeginUpdate / EndUpdate лучше поставить вокруг начального вызова FindFiles (как я понял, в обработчике нажатия Button2)
Строки

application.ProcessMessages;
frmAddPath.Label2.caption:=inttostr(frmADDPath.ListBox1.Items.Count);
Нужны ли? И если нужны, то нужны ли они так часто?

В лучшем варианте их поставить в обработчике нажатия Button2 после отработки рекурсии (тогда ProcessMessages можно убрать).
Ну или, хотя бы, снаружи repeat..until

← →
McSimm © (2002-09-17 15:10) [13]

Далее.

Проверка
if not (DirectoryExists(s+"\"+sr.name)) then listbox1.Items.add
Это некорректно. А если существует файл и папка с одиyfrjdsv именем?
Тогда этот файл будет проигнорирован.
Информация о том папка это или файл есть в sr:
if (sr.Attr and faDirectory) = 0 then ...

Проверка if (DirectoryExists(s+"\"+sr.name)) then FindFiles(s+"\"+sr.Name);
Выполняется дважды. Перед вызовом процедуры и при входе.
Да и нужна ли она вообще?

← →
Zion © (2002-09-17 17:15) [14]

Ок. Исправлю. Спасибо за рецензии =)...

← →
Zion © (2002-09-17 20:17) [15]

А так????

procedure TForm1.FindFiles(s:String);
var
Sr:TSEARCHREC;

begin

try

findFIRST(s+"\"+frmAddPath.Edit2.Text ,faAnyFile,sr);

application.ProcessMessages;

frmAddPath.Label2.caption:=inttostr(frmADDPath.ListBox1.Items.Count);

repeat

if (sr.name="..") or (sr.name=".") then continue;

if (sr.Attr and faDirectory)=0 then

frmAddPath.listbox1.Items.add(StringReplace(s+"\"+sr.name,"\\","\",
[rfReplaceAll]))

else

FindFiles(s+"\"+sr.Name);

until (FindNeXT(sr)<>0) or (frmAddPath.Button2.Caption="Найти");

finally
FindClose(sr);
end;
end;

← →
Black_jek (2002-09-17 20:50) [16]

Зи - работай -)) = у тебя всё ещё в переди - как и у меня -:D)

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

Спасибо, нашел =)..

А все-таки вопрос о скорости поиска файлов остался открытым!!!

Да да... и все почему-то молчат, хотя вот этот вариант (который я написал) ищет все файлы на моем диске D: (7520) за 1.5 сек.
Вот... А все-таки кто-нить мне расскажет в чем ошибка в моем коде?

← →
Dmitry Toropov (2002-09-19 17:49) [21]

2Eugene
думаю, что вопрос просто-напросто в использовании нескольких потоков. Т.е. по мере наполнения TListView достаточным количеством информации, чтобы закрыть (заполнить) окно, список отражается, а во время пауз происходит "досчитывание файлов". Например, если открыть каталог, содержащий большое количество объектов и сразу же нажать клавишу PgDn, то будет отчетливо слышно, что винт работает ...

← →
Gandalf (2002-09-19 18:59) [22]

>2Eugene
>думаю, что вопрос просто-напросто в использовании нескольких >потоков. Т.е. по мере наполнения TListView достаточным
Согласен.
Вспомним Бред - кажется, что он все быстро грузит, на самом он грузит не так уж быстро, но в одном потоке отображает что загрузил, в другом грузит дальше. Не помню только в оригинальном или в одной из переработок.

а кто такой Бред?

FindFirst и все все все =) Найти похожие ветки