Autor Beitrag
retnyg
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2754

SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
BeitragVerfasst: So 23.10.05 18:20 
user profile iconHeiko hat folgendes geschrieben:
Mhm, du scheinst immer irgendwelche Fälle zu haben, die ich nicht teste ;).

:shock: eigentlich ziemlich naheliegend :eyecrazy:
user profile iconHeiko hat folgendes geschrieben:
@Suchbegriffsübergabe: Könnte man umgestalten, allerdings würde ich dann das | nehmen ;).
damit brichst du aber mit der syntax, die windows-weit von suchprogrammen verwendet wird :?

user profile iconHeiko hat folgendes geschrieben:
@globale Variable für die Rückgabe: Warum disqualifiziert die sich dann dort gleich? Man braucht ja nur den Wert immer in eine andere Variable speichern, wodurch dann paralleles Suchen und auswerten der einzelnen Ergebnisse möglich wäre. Das gleiche würde man ja machen, wenn man parallel Suchen und Auswerten will, wenn man das Array als Parameter übergibt ;).

falsch: bei meiner variante kann ich 2 versch. threads mit 2 versch. variablen laufen lassen, ohne dass die sich gegenseitig im speicher rumpfuschen

user profile iconHeiko hat folgendes geschrieben:
@Testen: Wie gesagt ich nutzte eigentlich nur v1.0, da ich nur die Endungen brauche, und da gibt es keine Probleme mit Mehrfachfilterung. Es kann eigentlihc nur daran leigen, das ich wahrscheinlich den Filter nur einmal rüberjage anstatt mehrmals ;).

tja, wenn du hier eine unit reinstellst solltest du sie schon testen, auch wenn du sie selber nicht verwendest.
sonst könntest du gleich folgende prozedur hier anbieten:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
procedure findFiles(root, mask: string);
asm 
  nop
end;

das resultat ist (oder war) in einigen fällen gleich wie bei dir, aber um einiges schneller :lol:

_________________
es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
Heiko Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 3169
Erhaltene Danke: 11



BeitragVerfasst: So 23.10.05 18:32 
user profile iconretnyg hat folgendes geschrieben:
user profile iconHeiko hat folgendes geschrieben:
Mhm, du scheinst immer irgendwelche Fälle zu haben, die ich nicht teste ;).

:shock: eigentlich ziemlich naheliegend :eyecrazy:
user profile iconHeiko hat folgendes geschrieben:
@Suchbegriffsübergabe: Könnte man umgestalten, allerdings würde ich dann das | nehmen ;).
damit brichst du aber mit der syntax, die windows-weit von suchprogrammen verwendet wird :?

Mhm, denn kenne ich nicht, den mir ist noch kein solches Verfahren aufgefallen wo es so ist. Ich wollte den Filter so aufbauen wie bei einem OpenDialog etc. Aber wenn du sagst das es Standard ist werde ich mich dem Standard anschließen ;).

user profile iconretnyg hat folgendes geschrieben:
user profile iconHeiko hat folgendes geschrieben:
@globale Variable für die Rückgabe: Warum disqualifiziert die sich dann dort gleich? Man braucht ja nur den Wert immer in eine andere Variable speichern, wodurch dann paralleles Suchen und auswerten der einzelnen Ergebnisse möglich wäre. Das gleiche würde man ja machen, wenn man parallel Suchen und Auswerten will, wenn man das Array als Parameter übergibt ;).

falsch: bei meiner variante kann ich 2 versch. threads mit 2 versch. variablen laufen lassen, ohne dass die sich gegenseitig im speicher rumpfuschen
Jetzt ist mir klar was du meinst ;). Wobei eine parallele Suche sowieso nix bringt, da eine Festplatte ja davon nicht schneller wird und nur der Lesekopf der Festplatte dauernd sich hin und her bewegen muss, wodurch die lesegeschwindigkeit sich verringert ;). Außerdem braucht man das ja eigentlich nicht durch den Mehrfachfilter ;).

user profile iconretnyg hat folgendes geschrieben:
user profile iconHeiko hat folgendes geschrieben:
@Testen: Wie gesagt ich nutzte eigentlich nur v1.0, da ich nur die Endungen brauche, und da gibt es keine Probleme mit Mehrfachfilterung. Es kann eigentlihc nur daran leigen, das ich wahrscheinlich den Filter nur einmal rüberjage anstatt mehrmals ;).

tja, wenn du hier eine unit reinstellst solltest du sie schon testen, auch wenn du sie selber nicht verwendest.

Mhm, ich teste die schon, aber nicht mit allen Möglichkeiten die es gibt ;) Ich habe die Unit immer nur mit einem Filter getestet, da ich immer gleich die Performance mit der driveTools verglichen habe und ich da weiß, das die DT bei Suche mehrerer Dateien langsamer ist ;).

user profile iconretnyg hat folgendes geschrieben:
sonst könntest du gleich folgende prozedur hier anbieten:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
procedure findFiles(root, mask: string);
asm 
  nop
end;

as resultat ist (oder war) in einigen fällen gleich wie bei dir, aber um einiges schneller :lol:

Stimmt, die Variante wäre schneller ;).


Hast du jetzt eigentlich mal die Performance zwischen deiner und meiner jetzt funktionierenden Verglichen?
retnyg
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2754

SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
BeitragVerfasst: So 23.10.05 20:30 
user profile iconHeiko hat folgendes geschrieben:

Mhm, denn kenne ich nicht, den mir ist noch kein solches Verfahren aufgefallen wo es so ist. Ich wollte den Filter so aufbauen wie bei einem OpenDialog etc. Aber wenn du sagst das es Standard ist werde ich mich dem Standard anschließen ;).

musst nur mal im explorer nach *.jpg; *.jpeg; *.gif suchen
oder in deinem mailprogramm nach hallo; heiko
user profile iconHeiko hat folgendes geschrieben:
Jetzt ist mir klar was du meinst ;). Wobei eine parallele Suche sowieso nix bringt, da eine Festplatte ja davon nicht schneller wird und nur der Lesekopf der Festplatte dauernd sich hin und her bewegen muss, wodurch die lesegeschwindigkeit sich verringert ;). Außerdem braucht man das ja eigentlich nicht durch den Mehrfachfilter ;).

ed gibt auch leute, die besitzen mehr als eine festplatte

user profile iconHeiko hat folgendes geschrieben:
Hast du jetzt eigentlich mal die Performance zwischen deiner und meiner jetzt funktionierenden Verglichen?

das überlasse ich dir und dem publikum: siehe anhang
da drin ist meine unit, ein testprogramm, sowie deine und luckies unit
Einloggen, um Attachments anzusehen!
_________________
es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: So 23.10.05 20:57 
user profile iconretnyg hat folgendes geschrieben:

da drin ist meine unit, ein testprogramm, sowie deine und luckies unit

Das ist ja immer noch die alte. Ich habe doch schon daraufhingewiesen, dass es eine neue gibt.

Und mach mal die ganzen Warnungen und Hinweise aus dem Quellcode raus, das sieht ja schrecklich aus.
Heiko Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 3169
Erhaltene Danke: 11



BeitragVerfasst: Mo 24.10.05 07:55 
So, ich habe mal in meinem Vergleichsprojekt die retFileSearch (die in dem einen Anhang dabei war) und die mpuDriveTools von Luckies Seite eingebaut:

ausblenden volle Höhe Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
unit Unit1;

interface

uses
  Windows, SysUtils, Forms, Dialogs, StdCtrls, Classes, Controls;

type
  TForm1 = class(TForm)
    Button4: TButton;
    procedure Button4Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation
  uses mpuDriveTools, SearchTool, retFileSearch;
{$R *.dfm}

procedure TForm1.Button4Click(Sender: TObject);
var
  i: Integer;
  Zeit1, Zeit2, Zeit3, StartZeit: Cardinal;
  ST: TStringArray;
  FS: TArray;
  FindFiles: TFindFiles;
  Found: Integer;
begin
  SetLength(ST, 1);
  ST[0]:='*.MP3';
  FindFiles:=TFindFiles.Create(Form1.Handle, 'C:\''*.MP3', true, false);
  for i:=0 to 1 do
  begin
    SearchTool.SearchFiles('C:\', ST, true);
    FindFiles.Init;
    FindFiles.FindFiles;
    Found:=retfilesearch.FindAllFiles('C:\''*.MP3', FS, nil, true, false, true);
  end;
  Zeit1:=0;
  Zeit2:=0;
  Zeit3:=0;
  for i:=0 to 1 do
  begin
    StartZeit:=GetCurrentTime;
    SearchTool.SearchFiles('C:\', ST, true);
    inc(Zeit1, GetCurrentTime-StartZeit);

    StartZeit:=GetCurrentTime;
    FindFiles.Init;
    FindFiles.FindFiles;
    inc(Zeit2, GetCurrentTime-StartZeit);

    StartZeit:=GetCurrentTime;
    Found:=retfilesearch.FindAllFiles('C:\''*.MP3', FS, nil, true, false, true);
    inc(Zeit3, GetCurrentTime-StartZeit);
  end;
  ShowMessage('ST: '+IntToStr(Zeit1 div 2)+' ms'+#13+
              'gefundene Dateien: '+IntToStr(SearchTool.cntFoundFiles)+#13+
              'DT: '+IntToStr(Zeit2 div 2)+' ms'+#13+
              'gefundene Dateien: '+IntToStr(FindFiles.InstanceSize)+#13+
              'FS: '+IntToStr(Zeit3 div 2)+' ms'+#13+
              'gefundene Dateien: '+IntToStr(Found));
end;

end.


Ergebnis:
- SearchTool(v2.0.3): 4164 ms
- DriveTools(v3.0): 7437 ms
- retFileSearch (v4): 6695 ms

Zum Ergebnis muss ich allerdings ein noch sagen. Bei Luckie werden die gefundenen Pfade nicht eingespeichert (oder ich habe nix gefunden wo es gemacht wird), dadurch entfällt ja die Zugriffs- und Schreibezeit auf dem RAM. Des weiteren ließ sich bei Luckie nicht überprüfen, ob er genauso wiel Dateien gefunden hat, da wie gesagt er nirgendswo etwas zusätzlich einspeichert ;).

Allerdings kam die Units nicht ganz vergleichen, denn jede Unit bietet mehr oder weniger zusätzliche Schnittstellen, die die Performance evtl. verlangsamen. Aber vom reinen Suchen dürfte es auf jeden Fall zu sehen sein, welche Unit die Nase vorne hat ;) :D .
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Mo 24.10.05 12:44 
user profile iconHeiko hat folgendes geschrieben:
Bei Luckie werden die gefundenen Pfade nicht eingespeichert (oder ich habe nix gefunden wo es gemacht wird)

Das wird dir doch alles per Nachricht zu geschickt.
retnyg
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2754

SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
BeitragVerfasst: Mo 24.10.05 17:07 
user profile iconHeiko hat folgendes geschrieben:

Ergebnis:
- SearchTool(v2.0.3): 4164 ms
- DriveTools(v3.0): 7437 ms
- retFileSearch (v4): 6695 ms

deine unit ist in der tat die schnellste, nachdem die dateisuche von windows gecached wurde.
die resultate von dir sind gecachte messzeiten.
mach mal deinen speicher voll (z.b. n delphi-prog das mit getmem viel speicher alloziert), so dass der wert "zugesichter speicher" im taskmanager grösser als der wert deines physikalischen arbeitsspeicher ist.
so werden die suchen nicht gecached, und du siehst welche strategie beim reinen festplattenhandling die nase vorn hat.
bei meinen messungen waren hier alle 3 units gleichschnell (abweichungen/schwankungen bis zu 3-4%), allerdings bei unterschiedlichem funktionsumfang.

_________________
es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
retnyg
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2754

SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
BeitragVerfasst: Mo 24.10.05 18:55 
user profile iconretnyg hat folgendes geschrieben:
deine unit ist in der tat die schnellste, nachdem die dateisuche von windows gecached wurde.

nein, das stimmt so nicht: deine unit nur die schnellste, wenn man nur nach einem dateityp sucht.
sucht man nach *.* oder *.mp3;*.m3u ist meine schneller. wenn man bei meiner unit nach *.mp3;*.mp3 sucht ist sie doppelt so schnell als nur bei *.mp3 :lol:
das werde ich noch optimieren.

_________________
es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
Heiko Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 3169
Erhaltene Danke: 11



BeitragVerfasst: Mo 24.10.05 19:18 
user profile iconLuckie hat folgendes geschrieben:
user profile iconHeiko hat folgendes geschrieben:
Bei Luckie werden die gefundenen Pfade nicht eingespeichert (oder ich habe nix gefunden wo es gemacht wird)

Das wird dir doch alles per Nachricht zu geschickt.


Jupp weiß ich, des wegen findet man ja auch nix, wo etwas eingespeichert wurde ;). Da ich aber nicht noch was zusätzlich einbauen wollte, wo evtl. Performance verloren geht, konnte ich keine Verhgleiche ziehen, ob er wirklich alles gefuden hat ;).

user profile iconretnyg hat folgendes geschrieben:
user profile iconretnyg hat folgendes geschrieben:
deine unit ist in der tat die schnellste, nachdem die dateisuche von windows gecached wurde.

nein, das stimmt so nicht: deine unit nur die schnellste, wenn man nur nach einem dateityp sucht.
sucht man nach *.* oder *.mp3;*.m3u ist meine schneller. wenn man bei meiner unit nach *.mp3;*.mp3 sucht ist sie doppelt so schnell als nur bei *.mp3 :lol:
das werde ich noch optimieren.


Gemerkt das du dir selber widersprochen hast? Erst machste eine Aussage, danch zitierst du dich selber und bahauptest das die Aussage falsch ist ;). Das er bei *.mp3;*.mp3 doppelt so lange braucht ist eine gute Idee noch zu verbessern ;).

@Cache: Eigentlich nutzt jede Unit von uns den Cache. Zu mindestens war es bei der DriveTools von Luckie das gleiche Symton und ich glaube nicht das er es entfernt hat, was ja Nachteilig wäre ;). Und ich so weit iczh gesehen habe beruhhst du auf dem gleichem Symtom. Von daher ... ;).
retnyg
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2754

SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
BeitragVerfasst: Mo 24.10.05 19:39 
user profile iconHeiko hat folgendes geschrieben:
Gemerkt das du dir selber widersprochen hast?

nein, ich habe nur was richtiggestellt.

also: aus dem cache heraus ist deine unit die schnellste, wenn man nur nach einem dateityp sucht.
bei allen anderen aufgaben ist meine unit schneller.
deswegen die berichtigung.
user profile iconHeiko hat folgendes geschrieben:
Das er bei *.mp3;*.mp3 doppelt so lange braucht ist eine gute Idee noch zu verbessern ;).
nein, es ist genau umgekehrt.
user profile iconHeiko hat folgendes geschrieben:
@Cache: Eigentlich nutzt jede Unit von uns den Cache. Zu mindestens war es bei der DriveTools von Luckie das gleiche Symton und ich glaube nicht das er es entfernt hat, was ja Nachteilig wäre ;). Und ich so weit iczh gesehen habe beruhhst du auf dem gleichem Symtom. Von daher ... ;).

ja, zum cache: wenn der code im alltag hergenommen wird, läuft der code zu 90% `NICHT aus dem cache.
wenn ich nach etwas suche, dann normalerweise nur 1x, und nicht 10mal um die zeit zu messen.

deshalb ist der wert, der für die praxis interessanter ist, der ungecachte.

wenn du die performance-krone für die dateisuche willst, musst du mehr testen als nur den einen bereich, wo dein code die nase vorn hat. sonst ist das wie bei intel, die ihre benchmarks für die eigenen cpu's optimieren :roll:

_________________
es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
Heiko Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 3169
Erhaltene Danke: 11



BeitragVerfasst: Mo 24.10.05 19:55 
user profile iconretnyg hat folgendes geschrieben:
user profile iconHeiko hat folgendes geschrieben:
Das er bei *.mp3;*.mp3 doppelt so lange braucht ist eine gute Idee noch zu verbessern ;).
nein, es ist genau umgekehrt.


Das ist wirklich komisch ;). Aber bei mir stimmt das nicht. Wenn man 2x den geleichen Filter verwendet kommt das "erhoffte" Ergebnis das sie langsamer ist, was auch der Fall ist bei meiner Unit.
retnyg
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2754

SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
BeitragVerfasst: Mo 24.10.05 20:25 
wenn du gerade am debuggen bist: deine aktuelle variante liefert bei *.* oder * zu wenig treffer

_________________
es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
Heiko Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 3169
Erhaltene Danke: 11



BeitragVerfasst: Di 25.10.05 06:48 
Mhm, wenn ich bei mir vergleiche wieviel Daten auf C sind und wieviel er findet stimmen die schon. Meine Unit findet 133.037 Dateien und wenn ich bei C Strg+A und dann Eigenschaftenm mache, findet er 132.921 Daten. Warum er mehr findet kann ich dir gerade nicht sagen, aber es kann kein Bug sein vom Filter, denn der würde maximal verusrachen, das zu wenige da sind. Evtl. macht er bei den Egenschaften Systemdaten nicht mit, während die Unit ein paar Typen vom System noch findet.
Aber wie kommste darauf das er zu wenig findet? Findet er bei dir etwa nicht alle (v2.0.3?)?
retnyg
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2754

SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
BeitragVerfasst: Di 25.10.05 13:56 
der explorer sagt auf E: liegen 176.000 dateien.
das selbe sagt auch meine unit.
deine neueste unit sagt es wären 171.000

_________________
es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
Heiko Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 3169
Erhaltene Danke: 11



BeitragVerfasst: Di 25.10.05 16:31 
Ich habs vermutet dass du mit der Windowssuche vergleichst. Das Ergebnis stimmt jedoch nicht ganz, denn die Windowssuche sucht auch in zip-Dateien nach Dateien, während meine zip-Archive nicht durchsucht. Des wegen dieser Unterschied ;). Würde mich aber mal interessieren, warum deiner die findet ;).
retnyg
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2754

SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
BeitragVerfasst: Di 25.10.05 16:51 
wer redet von suchen ? E: öffnen, STRG-A, ALT-ENTER

_________________
es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
mimi
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3458

Ubuntu, Win XP
Lazarus
BeitragVerfasst: So 06.11.05 11:21 
So eine unit habe ich schon lange gesucht, ich habe sie jetzt zwar noch nicht getestet aber kann ich denn beim suchen die unterverzeichnise ausschalten ?
also so das nur das hauptverzeichnis durchsucht wird und nicht die andren die es evtl. noch geben könnte.

So mal schauen welche unit ich nehme, warscheinlich die von
"retnyg"
evlt. teste ich auch mal alle ich habe ein verzeichnis mit über 3000 midi dateien *G* ich fände es auserdem nicht schlecht wenn eine datei gefunden wird ein ereignis ausgelöst wird. Das hat den vorteil das ich die gefunden dateien nicht erst umwandel muss.

aber dies sollte ein und ausgeschlatet werden können.

_________________
MFG
Michael Springwald, "kann kein englisch...."
Heiko Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 3169
Erhaltene Danke: 11



BeitragVerfasst: So 06.11.05 11:33 
user profile iconmimi hat folgendes geschrieben:
So eine unit habe ich schon lange gesucht, ich habe sie jetzt zwar noch nicht getestet aber kann ich denn beim suchen die unterverzeichnise ausschalten ?

Ob die Unterordner mit durchsucht werden sollen oder nicht, kannst du bei allen 3 Units angeben.

user profile iconmimi hat folgendes geschrieben:
evlt. teste ich auch mal alle ich habe ein verzeichnis mit über 3000 midi dateien *G*

Bei midi dürfte mein Filter keine Probleme haben. ICh habe den Bug schon gefunden, aber bisher keine Zeit gehabt den auszubessern, da ich beim BwInf teilnehme.

user profile iconmimi hat folgendes geschrieben:
ich fände es auserdem nicht schlecht wenn eine datei gefunden wird ein ereignis ausgelöst wird. Das hat den vorteil das ich die gefunden dateien nicht erst umwandel muss.

aber dies sollte ein und ausgeschlatet werden können.

Was meinst du mit umwandeln? Und das mit dem Ereignis kann momentan Luckies Unit, wenn ich dich richtig verstanden habe, was du haben willst ;).
retnyg
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2754

SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
BeitragVerfasst: So 06.11.05 14:11 
user profile iconmimi hat folgendes geschrieben:

evlt. teste ich auch mal alle ich habe ein verzeichnis mit über 3000 midi dateien *G* ich fände es auserdem nicht schlecht wenn eine datei gefunden wird ein ereignis ausgelöst
aber dies sollte ein und ausgeschlatet werden können.


ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
procedure callback (x:integer;t:tarray);
begin
   form1.Memo1.Lines.add(t[x]);
   application.ProcessMessages;
end;

procedure TForm1.Button2Click(Sender: TObject);
var liste: retfilesearch.tarray;
begin
  retfilesearch.FindAllFiles('C:\winxp\','*.mid',liste,callback,true);
end;


ahja und wegen unterverzeichnisse ned durchsuchen: statt dem true hinter callback ein false

_________________
es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
mimi
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3458

Ubuntu, Win XP
Lazarus
BeitragVerfasst: So 06.11.05 15:01 
@Heiko
mit umwanden meine ich z.b.: meistens wird ja eine TStringList erwartet aber wenn dies nicht der fall währe so wie bei luckie dort habe ich gelesen wird ein TStringArray erwartet.

aber wenn lucki's such funktioen ereignis unterstützt werde ich das in zukunpft verwenden. ja oder evlt. doch die von retnyg....

ich habe mir dem umfang noch nicht angeschaut nur mal die geschwindigkeits vergleiche, aber dies ist doch auch nur relativ: Das kommt doch auch drauf an wie schnell die festplatten sind und wie sie ausgelastet sind...

_________________
MFG
Michael Springwald, "kann kein englisch...."