![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
FindFirst и все все все =) [D6, WinXP]
Zion © (2002-09-16 15:09:00)Люди, кто знает, есть ли функция более быстрая чем FindXXX или можен нужен более быстрый алгорритм, я незнаю, но тот чтоя писал работает оч. медленно. Он просто все фалы в дириктории (и в поддериктории) добавляет в TLISTBox. Поиск по подкаталогам я оформил в виде рекурсии (как ни странно =))... вот.. но все работает оч. медленно... незнаю даже почему
Zion (2002-09-19 19:14:00) [1]а кто такой Бред?
Gandalf (2002-09-19 18:59:00) [2]>2Eugene
>думаю, что вопрос просто-напросто в использовании нескольких >потоков. Т.е. по мере наполнения TListView достаточным
Согласен.
Вспомним Бред - кажется, что он все быстро грузит, на самом он грузит не так уж быстро, но в одном потоке отображает что загрузил, в другом грузит дальше. Не помню только в оригинальном или в одной из переработок.
Dmitry Toropov (2002-09-19 17:49:00) [3]2Eugene
думаю, что вопрос просто-напросто в использовании нескольких потоков. Т.е. по мере наполнения TListView достаточным количеством информации, чтобы закрыть (заполнить) окно, список отражается, а во время пауз происходит "досчитывание файлов". Например, если открыть каталог, содержащий большое количество объектов и сразу же нажать клавишу PgDn, то будет отчетливо слышно, что винт работает ...
Zion (2002-09-18 19:23:00) [4]Да да... и все почему-то молчат, хотя вот этот вариант (который я написал) ищет все файлы на моем диске D: (7520) за 1.5 сек.
Вот... А все-таки кто-нить мне расскажет в чем ошибка в моем коде?
pasha_golub (2002-09-18 16:40:00) [5]А все-таки вопрос о скорости поиска файлов остался открытым!!!
Zion (2002-09-18 15:11:00) [6]Спасибо, нашел =)..
Anatoly Podgoretsky (2002-09-17 21:13:00) [7]Слушай не мучайся возьми примеры из ЧаВо, а так у тебя одна сплошная ошибка
Black_jek (2002-09-17 20:50:00) [8]Зи - работай -)) = у тебя всё ещё в переди - как и у меня -:D)
Zion (2002-09-17 20:17:00) [9]А так????
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;
Zion (2002-09-17 17:15:00) [10]Ок. Исправлю. Спасибо за рецензии =)...
McSimm (2002-09-17 15:10:00) [11]Далее.
Проверка
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);
Выполняется дважды. Перед вызовом процедуры и при входе.
Да и нужна ли она вообще?
McSimm (2002-09-17 15:05:00) [12]Не так.
BeginUpdate / EndUpdate надо окружать множественные изменения, а не одно. Иначе нет смысла (кстати, begin .. end после then забыл?)
Поэтому BeginUpdate / EndUpdate лучше поставить вокруг начального вызова FindFiles (как я понял, в обработчике нажатия Button2)
Строки
application.ProcessMessages;
frmAddPath.Label2.caption:=inttostr(frmADDPath.ListBox1.Items.Count);
Нужны ли? И если нужны, то нужны ли они так часто?
В лучшем варианте их поставить в обработчике нажатия Button2 после отработки рекурсии (тогда ProcessMessages можно убрать).
Ну или, хотя бы, снаружи repeat..until
Shaman_Naydak (2002-09-17 15:04:00) [13]Родной, ну что ты написал.. сам хоть подумал?
Лочить листбокс надо до 1-го вызова FindFiles и отпускать после отработки
Жуткий текст.. нет FindCLose, не проверяется результат FindFirst, а используется DirectoryExists.. нет try-finally
Мда, батенька, тут надо трудиться и трудиться
Zion (2002-09-17 14:40:00) [14]Вот кстати сам алгоритм:
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="Найти");
Zion (2002-09-17 14:19:00) [15]MCSimm
Спасибо.
Сонг:
Да, и что это за функции? А линные имена поддерживают? =)
Zion (2002-09-17 14:18:00) [16]MCSimm
Спасибо.
Song
McSimm (2002-09-17 11:34:00) [17]ListBox.Items.BeginUpdate;
// рекурсия
ListBox.Items.EndUpdate;
Song (2002-09-17 09:14:00) [18]DN использует свои собственные ф-ии из BIOS, а не функции из io.sys как NC. Как следствие, DN и предлагет прямой достп к диску, что дало возможность использования в нём замечательной утилитки - реаниматора.
Eugene (2002-09-17 07:31:00) [19]А ведь на самом деле вопрос интересный.
Я еще года три назад пытался написать что-то типа NC под винды и столкнулся с такой проблемой: директория, сожержащая более 1000 файлов обрабатывалась более 2 секунд, к примеру DN открывал туже директорию мнгновенно. Возможно тормозит не метод а компонент TListView. В общем тогда я решения этой проблемы не нашел, правда нашел в сети аналог того, чего мне не хватало, поэтому проект закрыл, а вот вопрос остался, причем видимо не только у меня.
Zion (2002-09-16 18:28:00) [20]2 rea
Нет.... чесно говоря даже неподозреваю о чем это =)
McSimm
2 Song
И как это сделать?