@retnyg


Wie schreibe ich die Funktion um, dass ich alles in einer Listbox anzeigen lassen kann?

MFG
koller1

Einfach:

danke! Manchmal ist man aber auch wie vernagelt

So, nach einer Ewigkeit habe ich mich mal wieder an die "DF-Version" von SearchTool gesetzt um diese zu überarbeiten (da ich meine abgespeckte Variante in einem anderem Programm auch überarbeiten musste, auf Grund von größere Bauarbeiten ). Herausgekommen ist V 3.0 Alpha

Was gibt es neues?

• UniCode unterstützung

Warum nur Alpha?

• 1. UniCode-Filter konnte ich nicht ausführlich testen, da ich keine Dateien dafür da hatte (also mit russische Buchstaben scheint er ohne Probleme klar zu kommen, auch wenn die Dateiendung normal war )
  
• 2. Den Filter will ich noch ausbauen:
  
  • Momentan ohne Platzhalten (*), also wieder nur Dateiendungen*
    
  • Filter als String übergebbar

*Dateiendung = die letzten Zeichen der Länge des Filters werden verglichen (Also beim Filter "p3" findet er auch Dateien mit der endung *.mp3).

Falls ihr hier wieder Bugs findet, wäre es schön, wenn ihr es mir melden würdet.

PS: Da pro Beitrag nur 3 Anhänge erlaubt sind, ist der Demo-Source bei dem Beitrag angehängt (um die Demo zu kompilieren, braucht ihr die VirtualStringTree-Komponente)

So, ich habe nen kleinen BugFix eingeschioben. Bei Copy & Paste hatte ich vergessen eine Variable in einer if-Anweisung mit zu ändern (innerhalb des Vergleiches macht er sonst alles richtig ).

So noch eine kleine Info zur aktuellen Alpha. Und zwar wird diese momentan nicht von 95/98 und ME unterstützt, mangels UniCode-API. Wenn ich Zeit habe, mache ich demnächst die nächste Alpha, wo das Problem behoben ist.

Nach mehreren Experimenten und ein paar Hilfreiche ergänzungen ist es endlich so weit: es gibt eine Alpha 2 (ist noch keine Final, da der Filter noch keine Masken (mit "*" ) erlaubt ).

Was hat sich seit der letzten Alpha geändert?

• Filtereinstellungen verbessert (Filter werden nicht mehr als Array übergeben, sondern als String (durch ; getrennt)
  
• SearchTool in einen extra Thread ausgelagert (kann man optional abschalten )
  
• Win95, 98 und ME- Kompatibilität wieder hergestellt
  
• aktueller Suchordner auslesbar
  
• Filter wird jetzt auch auf Ordner angewendet

Solltet ihr irgendwelche Bugs oder Synchronisationsfehler (wenn ich eine Kleinigkeit vergessen habe zu Synchronisieren) finden, meldet sie mir bitte. Ich habe zwar eigentlich die Unit so ziemlich komplett durchgetestet, aber man übersieht doch einiges.


Ach so, noch ein Kommentar zur Demo: Sie basiert jetzt nicht mehr auf VirtualStringTree, damit auch alle User die Demo direkt ausprobieren können (D2006 Leute werden trotzdem ein Problem haben, da die Shell-Kompos nicht existieren ). Folglich werden bei UniCode-Dateien als ???-Dateien ausgegeben, da ja die Delphi-Kompos kein UniCode-Support haben (die Unit gibt die Dateien aber als UniCode-Bezeichnungen zurück ).

Beim letzten Upload ist eine Kleinigkeit daneben gegangen (bei mir auf dem Rechner, aber ka wieso ). Ich habe noch einen kleinen Bugfix reingenommen, wo XP meckert, aber 98 nicht (ob ein Laufwerk bereit ist oder nicht). Das hatte ich entfernt, da 98 nicht gemeckert hatte . Bleibt trotzdem bei der Bezeichnung Alpha 2 . Ich hoffe das jetzt keine Probleme mehr bei der Demo existieren, wenn ja bitte melden.

hi, ich habe deine komponente hergenommen, da sie mit widestrings umgehen kann.
allerdings hatte sie einige bugs und war relativ umständlich zu bedienen, weswegen ich sie etwas umprogrammiert habe.
ich häng sie mal an, vielleicht willst du ja was übernehmen.

Hallo,

ich gucks mir mal an, was du da alles geändert hast. Und guck mal, in wie fern die Änderungen was bringen . Besonders PathMatchSpecW werde ich mir mal unter die Lupe nehmen, in wie fern er von der Performance her ist .

Aber den den nervigsten Bug hast du trotzdem nicht gefunden, den ich lokal behoben habe, aber noch nicht hochgeladen habe . Und zwar warten die beim abbrechen mittels Breka ewig aufeinander, bedingt dadurch, dass ich im Thread und beim Abbrechen MsgWaitForMultipleObjects nehme, und die sich die Nachrichten gegenseitig wegnehmen. Bis ich aber die Final rausbringe, wirds ggf. noch ein bissl brauchen, da ich gucken möchte, ob es Vorteil bringt, wenn ich PeekMessage nehme, anstatt dauernd zu synchroniseren. Da hängt es davon ab, wie es von der Performane her ist.

Aber auf jeden Fall danke, dass du mich mal wieder an die Unit erinnert hast. Denn in meinem Projekt läuft die so, wie ich es will, wes wegen ich die schon wieder (fast) vergesseen habe .

//EDIT: Die Idee von QuickSearch ist auch mal wieder gut. Diese Variante ist leider von Version 2 auf 3 verloren gegangen .

Heiko hat folgendes geschrieben:

Aber den den nervigsten Bug hast du trotzdem nicht gefunden, den ich lokal behoben habe, aber noch nicht hochgeladen habe . Und zwar warten die beim abbrechen mittels Breka ewig aufeinander, bedingt dadurch, dass ich im Thread

liegt wohl daran, dass ich immer ohne thread vorgegangen bin, da ich alles sequentiell durcharbeite ohne mich mit callbacks rumzuschlagen. der part scheint nun fehlerfrei zu funktionieren.
du könntest die unit noch insoweit verbessern, dass wenn KEIN THREAD benutzt wird, du auf die criticalsections und locks verzichtest, da diese die performance doch ein bischen beeinträchtigen.

So, ich habs mir mal gerade anguckt.

0xCC hat folgendes geschrieben:

- Filtereinstellungen verbessert (WINAPI-Aufruf von PathMatchSpecW )

Ist natürlich die einfachere Variante, die ich auch aus probieren werde. Ich stolpere noch darüber:

Zitat:

Searches a string using an Microsoft MS-DOS wild card match type.

Denn mit MS-DOS verbinde ich immer die Begrenzung auf 8 Zeichen je Ordner/Datei. Ich hoffe mal, dass es bei der UniCode-Variante nicht der Fall ist .

0xCC hat folgendes geschrieben:

- Fehlerhafte Fileextension-Routine durch eigene ersetzt

Wo war die Fehlerhaft? Meine hat nur ein bisschen mehr zugelassen, als es für eine reine Fileextension der Fall wäre. Aber das ist ja nicht schlimm, sondenr hat sogar seine Vorteile. Wenn man z.B. nach "\Test.mp3" sucht, hat man den Fall, dass er alle Dateien raussucht, die Test.mp3 heißen (ohne \ wäre es *Test.mp3). Und Dateiendungen gingen damit auch, wie man in der Demo gesehen hat.
Und SearchTool soll schließlich nicht nur nach Dateiendungen suchen können, sondern genauso viel können, wie die Windows-Suchfunktion.

0xCC hat folgendes geschrieben:

- bug bei rekursiver ordnerstruktur, wenn FFindDirs = false, entfernt

Da haste Recht. Komisch, dass es mir gar nicht aufgefallen ist. Liegt wahrscheinlich daran, dass ich in meinem Projekt eine gekürzte Variante von ST nehme, damit keine unnötigen ASM-Codes drin sind, bei denen das Ergebnis feststeht .

0xCC hat folgendes geschrieben:

- wenn Zielhandle null ist, werden keine Messages verschickt

Auch da muss ich dir Recht geben. Bei mir war 0 = keine Nachricht versenden, da ungültiges Handle. Dass Windows das auf PostThreadMessage umbiegt kann man ja nicht ahnen (bei SendMEssage steht z.B. nüscht davon drin, wie er auf 0 reagiert).

0xCC hat folgendes geschrieben:

- Resetdata setzt nun die Länge der Dir und File-Arrays auf null, bevor der pointer auf nil geändert wird um speicherleaks zu vermeiden.

Im Gegenteil. Die Variante mit nil ist sogar besser, denn da ruft DynArrayClear auf (siehe CPU-Fenster), während er bei SetLength(..., 0) den Umweg über DynArraySetLength geht.

Eine erste Final kommt vlt. in den nächsten Tagen. Optimieren kann ichs später immer noch .

Heiko hat folgendes geschrieben:

Zitat: Searches a string using an Microsoft MS-DOS wild card match type. Denn mit MS-DOS verbinde ich immer die Begrenzung auf 8 Zeichen je Ordner/Datei. Ich hoffe mal, dass es bei der UniCode-Variante nicht der Fall ist .

das heisst nur dass die standard wildcards verwendet werden, wie beim dir-befehl, z.b *.mp? * *.*.
ich glaube, pathmatchspecw unterstützt sogar das folgende von haus aus: '*.mp3;*.wav;*.ogg' - da fiele sogar deine filtereexts tabelle weg.

Heiko hat folgendes geschrieben:

0xCC hat folgendes geschrieben: - Fehlerhafte Fileextension-Routine durch eigene ersetzt Wo war die Fehlerhaft? Meine hat nur ein bisschen mehr zugelassen, als es für eine reine Fileextension der Fall wäre. Aber das ist ja nicht schlimm, sondenr hat sogar seine Vorteile. Wenn man z.B. nach "\Test.mp3" sucht, hat man den Fall, dass er alle Dateien raussucht, die Test.mp3 heißen (ohne \ wäre es *Test.mp3). Und Dateiendungen gingen damit auch, wie man in der Demo gesehen hat. Und SearchTool soll schließlich nicht nur nach Dateiendungen suchen können, sondern genauso viel können, wie die Windows-Suchfunktion.

ähm also ganz genau kann ich mich nicht mehr erinnern, ich weiss aber noch dass die fileext. die der filter berechnet hat, bei mir komplett nicht stimmte, als ich mit dem debugger durchgesteppt bin.
und da deine filterfunktion nichtmal * oder *.* richtig erkannt hat, habe ich gleich die dafür vorgesehen windows-funktion verwendet.

Heiko hat folgendes geschrieben:

0xCC hat folgendes geschrieben: - Resetdata setzt nun die Länge der Dir und File-Arrays auf null, bevor der pointer auf nil geändert wird um speicherleaks zu vermeiden. Im Gegenteil. Die Variante mit nil ist sogar besser, denn da ruft DynArrayClear auf (siehe CPU-Fenster), während er bei SetLength(..., 0) den Umweg über DynArraySetLength geht.

aha ? kann sein, ich wollte mal auf nummer sicher gehen. jedenfalls ist bei der funktion die performance egal, da sie bei jeder suche ja nur einmal aufgerufen wird. dafür habe ich den aufruf von GetArbeitsplatzName wegoptimiert, so dass es nur einmal beim constructor einer variablen zugewiesen wird und nicht bei jeder suche.

[quote="0xCC"]

Heiko hat folgendes geschrieben:

ich glaube, pathmatchspecw unterstützt sogar das folgende von haus aus: '*.mp3;*.wav;*.ogg' - da fiele sogar deine filtereexts tabelle weg.

Jupp, funzt so. Habs schon ausprobiert (bevor du hier das gepostet hast). Und da Delphi sich um die Thread-Sicherheit bei Stringskümmert, wird der Code ein Stück kürzer, da ich mich darum nimmer kümmern muss . Und ich glaube nicht, dass ich diese Prozedur noch einmal selber schreiben werde, denn PathMatchSpec wird ja hoffentlich schon von Windows optimierts ein .
Aber dazu fällt mir noch was ein. Und zwar funzt deine Unit, also was du da geändert hast, nur noch unter den neueren OSes, denn du setzt voraus, dass die bekannt sind. Korrekt müsste es so hier sein:


Denn wenn man gleich

macht, so wie du es hattest, versucht Windows die DLL gleich beim start zu laden. Und wenn das S die Funktion nicht hat, gibts es eben nen Error. Von daher den Umweg über die Zweiteilung .

0xCC hat folgendes geschrieben:

und da deine filterfunktion nichtmal * oder *.* richtig erkannt hat, habe ich gleich die dafür vorgesehen windows-funktion verwendet.

Das unterstützte die Unit, in dem man einfach einen leeren Filter setzt .

0xCC hat folgendes geschrieben:

dafür habe ich den aufruf von GetArbeitsplatzName wegoptimiert, so dass es nur einmal beim constructor einer variablen zugewiesen wird und nicht bei jeder suche.

Jain. Ja klar ist es schneller. Aber gehe mal von einem Programm aus, dass 2h läuft. Bein Programmstart heißt der Arbeitsplatz noch "Arbeitplatz". Dann funzt es auch. Aber was ist wenn der Nutzter zwischendurch den Arbeitsplatz einfach mal umbennt zu "Mein PC". Dann würde die Optimierung eine Fehlermeldung verursachen, die ich nicht heraufbeschwöre. Von daher ist die Abfrage jedesmal erforderlich, außer man findet eine Möglichkeit diese Umbennung über Hooks oder so mitzubekommen. Dann wäre allerdings die Frage, ob Performancetechnisch vlt. nicht doch langsamer ist, da es ggf. keinen Extra-Hook dafür gibt, so dass man alle Änderungen am Dateisystem überwachen muss. Von daher lasse ich es so .

//EDIT: Einen Beitrag von dir übersehen

0xCC hat folgendes geschrieben:

du könntest die unit noch insoweit verbessern, dass wenn KEIN THREAD benutzt wird, du auf die criticalsections und locks verzichtest, da diese die performance doch ein bischen beeinträchtigen.

Looks verwende ich ja nur, wenn irgendeine Property geändert wird. Von daher spielt es da keine Rolle, denn man ändert ja nicht aller 5ms die Configs . Ansonsten wäre eine Zusätzliche if-Abfrage erforderlich, die auch nicht gerade gut für die Performance ist .

wenn das OS die funktion nicht hat läuft das programm eh nicht - ob dann die fehlermeldung früher oder später kommt ist sicher wurst.

dass ein leerer filter gleich '*.*' ist, kann man auch nicht riechen.

und von leuten, die ihren arbeitsplatz umbenennen, hab ich auch noch nie gehört.

so long

0xCC hat folgendes geschrieben:

wenn das OS die funktion nicht hat läuft das programm eh nicht - ob dann die fehlermeldung früher oder später kommt ist sicher wurst.

Nein. Ich Unterscheide zwischen UniCodefähigen-OSes und welchen, die es nicht sind. (Ansonsten wäre der Code nur halb so lang). Und nur durch solche Unterschieudngen ist es möglich, dass meine Unit unter allen OSes ab 95 laufen . Ich bekomme dann also keine Fehlermeldung.

0xCC hat folgendes geschrieben:

dass ein leerer filter gleich '*.*' ist, kann man auch nicht riechen.

Spätestens bei der Code-Überarbeitung hätte es dir auffallen müssen .

0xCC hat folgendes geschrieben:

und von leuten, die ihren arbeitsplatz umbenennen, hab ich auch noch nie gehört.

Ich auch nicht. Aber da es möglich ist... .Und shcließlich wirds nur einmal am Anfang der Suche aufgerufen, von daher spielt das noch keine große Rolle. Es spielt eigentlich nur das was sich in der Rekusion befindet eine Rolle.


Du weißt doch:

Zitat:

Es ist schwierig, ein Programm wirklich idiotensicher zu machen, weil Idioten so genial sind.

Schade Hatte gehofft , das die Pas datei schneler sucht als Windows.
Dem is doch nicht so aber trozdem eien Schöne Komponente
Auf jedenfall zu Gebrauchen.

Simak hat folgendes geschrieben:

Schade Hatte gehofft , das die Pas datei schneler sucht als Windows.

Ich habs heute früh mal getestet. Ein bissl schneller ist Windows im Vergleich (335ms vs. 310ms). Das würde ich vlt. erreichen, wenn ich is auf ASM-Ebene runter optimiere. Aber den Stress tue ich mir erst einmal nicht an . Aber war ja bald zu vermuten, denn MS sucht alle möglichen Dinge zum optimieren raus . Allerdings hängt die Suchgeschwindigkeit eher von der GUI-Geschwindigkeit ab...

//EDIT: An einer Stelle ein leerzeichen vergessen, so dass der Sinn verzerrt war .

Hu? dann hab ich wohl was falsch geamcht
Dein Suchtool: ~330sec
Windows Scuhe: ~70sec

Warum is bei dir son kliner unterschied und bei mir sno großer und dabei hat windoof sucher noch mehr mp3s gefunden o.O

Hatte ich ja gesagt. Nur durch einen "kleinen" Tippfehler, klang es vlt. bissl anders. Habs jetzt so geändert,d ass man es ordentlich erkennt, was ich meine

@Geschwindigkeit: Um die Suchgeschwindigkeit von Programmen vergleichen zu können, muss man vorher einen Suchlauf starten, der nicht in die Zeitmessung eingeht. Oder du startsest zwischen des Tests den Rechern neu, wobei beide Tests mit frisch gestartetem Betriebssystem sein sollte, um Gleichheit hervorzurufen. Kannst ja den Test nocheinmal machen. Bei mir war Windows eigentlich nie schneller (hast du mal die Demo von mir genommen? Denn die Standard-VCL ist arschlangsam . Und vergiss nicht: mkPostMessages oder mkNoneMEssage einzustellen (der Gerechtigkeit halber eher PosTmessage). Sonst bremst die VCL )

@Mehr Suchresultate: Liegt daran, dass Windows auch noch Archive durchsucht, was ich nicht mache .