Entwickler-Ecke
Freeware Projekte - Search-Tool 1.2.2.187
Delete - Fr 15.08.08 14:17
Titel: Search-Tool 1.2.2.187
Moin!
Ich habe mich in der letzten Woche ein bisschen hingesetzt und das ist dabei rausgekommen:
Name:Search-Tool
Version: 1.2.2.187
Beschreibung:
Search-Tool ist ein kleines Programm das einem im Alltag helfen kann.(AM PC)Es sucht wie man es schon hört nach einer oder mehreren Dateien. Aber nicht nur das. Es werden Informationen über jede gefundene
Datei bereitgestellt.Außerdem besitzt es ein Kopier- und ein Stringsuchtool.
Es ist aber kein besonders großes Programm.Mein Ziel ist es schneller als die Windowssuche zu sein.
Bis jetzt war das Programm bei meinen Tests nur minimal schneller. :oops:
ToDo-List:
-automatische Updatefunktion
-gefundene Dateien nach Kriterien filtern und sortieren
Bekannte Bugs
Bis jetzt noch keine.
Vielleicht habt ihr weitere Anregungen und Verbesserungsvorschläge für mich.
Ich freue mich auf alle Kritiken.
Viel Spaß beim Testen!
Delete - Sa 16.08.08 16:56
Ist er denn so schlecht?Gibs irgendwelche Probleme?
Ich werde morgen die neue Version uploaden.
wazup - Sa 16.08.08 17:12
Naja... Wenn ich auf C:\ nach *.exe suche findet er exakt 5 Dateien :lol:
Auserdem gibts doch schon ne suche von windows...
Christian S. - Sa 16.08.08 17:12
Hallo!
Ich hab's mir gerade mal angesehen. Mal meine Eindrücke in der Reihenfolge, wie sie mir auffallen:
- Eininge Labels sind nicht richtig ausgerichtet
- Die eigentliche Suchfunktion ist im Tools-Menü versteckt. Das finde ich wenig intuitiv
- Bei der Dateisuche werden noch Komponenten benutzt, die ich seit Windows 3.1 nicht mehr gesehen habe :shock:
- Die Suche blockiert das gesamte Programm. Der Button "Suchen" bleibt gedrückt, dann scheint das Programm sich aufzuhängen. Oder sucht fleissig. Hier fehlt also eine Status-Anzeige (am besten die gerade durchsuchte Datei, damit man sieht, dass das programm noch lebt)
- Unbdedingt einbauen: Ein Abbrechen-Button. Ich musste gerade den Prozess killen.
Insgesamt muss ich leider sagen, dass ich das Programm nicht mehr zeitgemäß finde. Sowohl Microsoft als auch Google bieten leistungsfähige Desktop-Suchmaschinen an, welche mit einem Index arbeiten, der im Hintergrund aufgebaut wird. Da hübsch in Vista integriert benutze ich die von MS. Wenn ich da in einem indizierten Ordner einen Begriff eingebe, habe ich nur ein maximal zwei Sekunden alle Dateien, die mit dem Begriff zu tun haben. Also nicht nur den Begriff im Namen tragen, sondern enthalten. Mit der Maschine von Google wird es sicherlich mindestens genauso schnell gehen.
Ich möchte Deine Leistung hier gar nicht schmälern oder Dich entmutigen. Es steckt sicehrlich jetzt schon viel Arbeit im Programm. Aber das Programm muss verdammt viel schneller werden, wenn es konkurrenzfähig sein will. Von einem Programm ohne Index (und das kann ja auch ein Merkmal Deines Programmes sein, nicht immer und überall will man einen Index haben oder hat Zugriff drauf) erwarte ich nicht, dass es so schnell ist wie ein index-basiertes Programm. Aber sehr viel schneller als das, wie es bisher ist, muss es IMHO schon sein.
Grüße
Christian
Delete - Sa 16.08.08 17:43
| Zitat: |
| - Bei der Dateisuche werden noch Komponenten benutzt, die ich seit Windows 3.1 nicht mehr gesehen habe :shock: |
Tja,das war geplant.Einfach Nostalgie pur!Das finden bestimmt viele gut! :mrgreen:
Spaß beiseite.Upps! :oops: Das werde ich dann wohl noch mal ändern.
| Zitat: |
| Naja... Wenn ich auf C:\ nach *.exe suche findet er exakt 5 Dateien :lol: |
Das finde ich eigenartig.Bei mir findet er 6587 Datein.Wie lange hat es gesucht. :?:
mfg,j.klugmann
Timosch - Sa 16.08.08 18:01
Muss auch Christian zustimmen: Dass die Suchfunktion im Menü versteckt ist, ist relativ unsinnig. Das gesamte Formular macht ja so zunächst mal gar keinen Sinn.
Ein Fortschrittsbalken, das Verwenden von Threads und ein gelegentliches Application.ProcessMessages wären auch ganz gut.
Den Bug mit zu wenig gefundenen Dateien kann ich reproduzieren: 2374 statt 2464.
Wieso kann man nur auf einzelnen Laufwerken/Ordnern und nicht überall suchen?
Außerdem sollte man Dateieigenschaften durchsuchen können (so à la "Nur Dateien, die vor dem soundsovielten erstellt wurden").
Bei der "Stringsuche" (hast du dir mal überlegt, woran Nicht-Programmierer bei dem Wort String denken??) wären reguläre Ausdrücke toll.
Wenn man eine Datei anklickt, sollten die Eigenschaften sofort angezeigt werden, nicht erst nach Klick auf Weiter.
Übrigens: Bei Zeit steht eine Null. Das waren aber definitiv mehr als null Sekunden...
Wieso hat das Programm keine Beenden/Minimieren/Maximieren-Buttons? Empfinde das als störend.
jaenicke - Sa 16.08.08 18:01
Ja, also grundsätzlich ist die Idee ja nicht schlecht, nur:
Dein Programm braucht für die Suche in C:\Programme nach *.txt 89 Sekunden und findet 1212 Dateien, die Windows-Suche blockiert während der Suche nicht, zeigt sofort an wo es ist und was es bisher gefunden hat und braucht 32 Sekunden... und findet 1255 Dateien!
Dann noch ein Bug: Man kann das Fenster gar nicht auf dem Bildschirm bewegen, was für ein solches kleines Tool (das man ja nebenbei benutzen will) natürlich katastrophal ist, schließlich reagiert ja auch nicht währenddessen und man kann es nicht auf die Seite schieben um zu sehen (hinter einem anderen Fenster zur Hälfte oder so) wann es fertig ist.
Delete - Sa 16.08.08 18:05
| Zitat: |
| Dann noch ein Bug: Man kann das Fenster gar nicht auf dem Bildschirm bewegen, was für ein solches kleines Tool (das man ja nebenbei benutzen will) natürlich katastrophal ist, schließlich reagiert ja auch nicht währenddessen und man kann es nicht auf die Seite schieben um zu sehen (hinter einem anderen Fenster zur Hälfte oder so) wann es fertig ist. |
das habe ich auch schon gemerkt. :wink: Allerdings kann ich den Fehler nicht finden.
Könnte man nicht die Suche mit fastmm4 erheblich verschnellern?Ich weiß es nicht :nixweiss: ?
mfg,j.klugmann
Timosch - Sa 16.08.08 18:08
 j.klugmann hat folgendes geschrieben: |
| Zitat: | | Dann noch ein Bug: Man kann das Fenster gar nicht auf dem Bildschirm bewegen, was für ein solches kleines Tool (das man ja nebenbei benutzen will) natürlich katastrophal ist, schließlich reagiert ja auch nicht währenddessen und man kann es nicht auf die Seite schieben um zu sehen (hinter einem anderen Fenster zur Hälfte oder so) wann es fertig ist. |
das habe ich auch schon gemerkt. :wink: Allerdings kann ich den Fehler nicht finden.
Könnte man nicht die Suche mit fastmm4 erheblich verschnellern?Ich weiß es nicht :nixweiss: ?
mfg,j.klugmann |
Delphi-Quelltext
1:
| Form1.BorderStyle:=bsSizeable; |
Christian S. - Sa 16.08.08 18:13
Frage zur Programmierung bitte weiterhin in den Programmier-Sparten des Forums stellen und beantworten. Danke! :-)
Delete - Sa 16.08.08 18:17
tja,das habe ich auch gedacht.funzt aber nicht. :?: :?: :?: :?:
Delete - Sa 16.08.08 19:10
Timosch | Zitat: |
| das Verwenden von Threads |
[user]
Verwende ich schon. :wink:
Christian S. - Sa 16.08.08 19:11
Wieso blockiert dann die GUI? :gruebel:
Delete - Sa 16.08.08 19:17
Genau das frag ich mich auch-arbeite noch dran.
Heiko - Sa 16.08.08 20:00
Hallo,
ich habe mir nach einem Hinweis gerade diesen Thread hier durchgelesen. Ohne jetzt dein programm zu testen ein paar Dinge zur Aufklärung.
| j.klugmann hat folgendes geschrieben: |
| Zitat: | | - Bei der Dateisuche werden noch Komponenten benutzt, die ich seit Windows 3.1 nicht mehr gesehen habe :shock: |
Tja,das war geplant.Einfach Nostalgie pur!Das finden bestimmt viele gut! :mrgreen: |
Ich hoffe doch nicht das du die Delphifunktionen (SearchRec) dazu nimmst. Diese sind so lahmarschig, dass sie 10x mehr Zeit benötigen als nötig (5min vs. 30sek dürften deutlich sein).
| Timosch hat folgendes geschrieben: |
| Den Bug mit zu wenig gefundenen Dateien kann ich reproduzieren: 2374 statt 2464. |
Und wieviele stecken davon in Archiven? 90? Im Gegensatz zur Windowssuche durchsucht die Windows-API(und dem entsprechend auch SearchRec) keine ZIP-Archive... Von daher nicht unbedingt ein Fehler, denn Programme können nicht direkt auf zip-Archive zugreifen...
| jaenicke hat folgendes geschrieben: |
Dein Programm braucht für die Suche in C:\Programme nach *.txt 89 Sekunden und findet 1212 Dateien, die Windows-Suche blockiert während der Suche nicht, zeigt sofort an wo es ist und was es bisher gefunden hat und braucht 32 Sekunden... |
Aha - war ein rechnerneustart dazwischen oder ein paar Stunden? Bestimmt nicht. Dann drehe mal den Spieß um. in dem Ordner erst mit der WinSuche suchen und dann mit dem Proggi. Was stellste fest? Genau, die WinSuche ist diesmal langsamer.- Ursache: Windows cacht seine Ergebnisse, von daher schwer vergleichbar - außer du startest die Zeitmessung erst nach einer Suche - denn dann kannste die Verarbeitungsgeschwindigkeit vergleichen, was nen bissl unabhängiger von der Platte sein sollte als die erste Suche.
| j.klugmann hat folgendes geschrieben: |
| Könnte man nicht die Suche mit fastmm4 erheblich verschnellern?Ich weiß es nicht :nixweiss: ? |
Jain. Erfahrungsgemäß beschleunigt FastMM4 RAM-intensive Programme um ca. 25%. Allerdings ist dein proggi nicht RAM intensiv, sondern Drive-intensiv. Von daher bringt es dir nicht soviel - schaden kann es allerdings nicht (schon alleine wegen dem finden von Speicherlecks...)
Und nun noch mein Hauptmotiv des schreibens hier. BEvor du das nächste mal ein Programm veröffentlichst gucke bitte, ob es etwas mit dem gleichen Namen schon gibt.
SEARCH-TOOL bzw
SEARCH-TOOLS um es deutlicher zu machen. Das Suchergebnis sollte dir übrigens auch bei deinem Threadproblem helfen :twisted:
€: @TUPFKAPL: Japp, da haste recht. Man bräuchte etwas was auch Dateien durchsucht (@klugman: gausi hat da was für die performance...). Ich suche immer noch für eine gute Alternative für InfoRapid. µ$ & google sind mir da nen bissl zu fett und zu ressourcenhungrig (bei google kann man nichtienmal ne festplatte formatieren wenn das teil aktiv ist -.-)
wazup - Sa 16.08.08 20:44
[quote="
j.klugmann"]
| Zitat: |
...
Das finde ich eigenartig.Bei mir findet er 6587 Datein.Wie lange hat es gesucht. :?:
... |
So um die 5 Sekunden...
Delete - Sa 16.08.08 21:18
WAS!!!! Dann auch noch so lange.Bei mir funktioniert es super!Er braucht zwar noch lange wenn
es 'C' durchsuchen soll,aber das es bei dir nicht funzt!
Jakob_Ullmann - Sa 16.08.08 21:51
Vielleicht hilft ein Application.ProcessMessages?
Delete - Sa 16.08.08 22:23
Wurde schon erwähnt.Hilft aber auch nicht viel.
Christian S. - Sa 16.08.08 22:33
Möchte nur noch mal hierauf hinweisen ;-)
| Christian S. hat folgendes geschrieben: |
| Frage zur Programmierung bitte weiterhin in den Programmier-Sparten des Forums stellen und beantworten. Danke! :-) |
jaenicke - So 17.08.08 09:42
| Heiko hat folgendes geschrieben: |
| jaenicke hat folgendes geschrieben: |
Dein Programm braucht für die Suche in C:\Programme nach *.txt 89 Sekunden und findet 1212 Dateien, die Windows-Suche blockiert während der Suche nicht, zeigt sofort an wo es ist und was es bisher gefunden hat und braucht 32 Sekunden... |
Aha - war ein rechnerneustart dazwischen oder ein paar Stunden? Bestimmt nicht. Dann drehe mal den Spieß um. in dem Ordner erst mit der WinSuche suchen und dann mit dem Proggi. Was stellste fest? Genau, die WinSuche ist diesmal langsamer.- Ursache: Windows cacht seine Ergebnisse, von daher schwer vergleichbar - außer du startest die Zeitmessung erst nach einer Suche - denn dann kannste die Verarbeitungsgeschwindigkeit vergleichen, was nen bissl unabhängiger von der Platte sein sollte als die erste Suche. |
Es handelt sich (wie bei fast allen Softwaretests, die ich durchführe) um eine virtuelle Maschine. Diese wird vor jedem Test auf den Originalzustand zurückgesetzt und dann erneut gestartet.
// EDIT: Selbst wenn ich die Windows-Suche ca. 50 Sekunden später starte wird sie noch
früher fertig als das hier vorgestellte Programm.
// EDIT2: Die Dateianzahl muss ich erneut überprüfen, in der virtuellen Maschine war die XP-interne Unterstützung für ZIP-Archive tatsächlich noch eingeschaltet. :oops:
Heiko - So 17.08.08 10:25
| jaenicke hat folgendes geschrieben: |
| // EDIT: Selbst wenn ich die Windows-Suche ca. 50 Sekunden später starte wird sie noch früher fertig als das hier vorgestellte Programm. |
Vergleiche die WinSuche mal bitte mit der Demo
hier [
http://www.delphi-forum.de/viewtopic.php?t=48936]. Theoretisch dürfte kein Unterschied bestehen. Die Demo dürfte also fdas Maximum darstellen, was man mit Delphi herausholen kann - und diese Unit kann klugmann auch bei sich einbauen, denn dann ist das Problem mit dem ProcessMessages weg :roll:
jaenicke - So 17.08.08 12:25
Habe ich gemacht, aber die Ergebnisse sind komisch. Die Windows-Suche brauchte für die Festplatte (bei einem realen PC diesmal) 5,5 Sekunden, dein Tool 3,5 Sekunden, auch bei Wiederholungen sind die Abweichungen davon minimal.
Das Tool aus dem Thread hier war beim ersten Mal mit 19,5 Sekunden sehr viel langsamer, dann mit 4 Sekunden sehr schnell, dann wieder bei 12,5 Sekunden, 6,5 Sekunden... Ich kann mir das nicht erklären. Der Zustand des PCs ist bei jedem Teststart zurückgesetzt. Allerdings ist die Festplatte des PCs auch zu klein um mit vielen Dateien verlässliche Ergebnisse zu liefern.
Auf dem ursprünglich getesteten System war die Suche bei einem weiteren Test im Rahmen (ca. 5 Sekunden Unterschied zur Windows-Suche), auch bei mehreren Tests.
Wir schweifen aber langsam etwas ab glaube ich, es geht ja nicht nur um die Performance.
Delete - So 17.08.08 17:18
Naja.Es ist ja so das mein tool alle gefundenen
dateien in ein Stringlist schreibt.Und es dauert eben lange wenn
man dann ne ganze stringlist übertragen muss (auf die Listbox).Die Suche selber ist nicht das Problem.
Delete - So 17.08.08 18:18
Es dauert jetzt noch ein bisschen bis zur nächsten Version.Rechnet mit ihr Mittwoch.
hab ja viel zu verbessern:
-Indexierungsdienst
-Thread
-Ausgabe des Suchergebnisses
-weitere Features
Heiko - So 17.08.08 18:28
Hallo,
wenn du mit Stringlisten arbeitest ist es ja kein wunder. Nimm VirtualStringTree. Das ist 1000x schneller ;)
Grüße
Heiko
Delete - So 17.08.08 18:30
Ups ich arbeite mit einem Array.Ich werds mal ausprobieren- :wink:
Heiko - So 17.08.08 18:50
Array kommt auf ziemlich das gleiche. Das Problem ist, dass Setlength dauernd aufgerufen wird. Wie oft rufste es auf? Bei jedem neuem Element? Das ist extrem lahmarschig. Wenn dann schon in größeren Schritten. Trotzdem wird VSt schneller sein, denn das basiert auf Zeigern. Der Overhead für die Zeiger lohnt sich imho - braucht aber auch nen bissl Erfahrung ;)
Delete - So 17.08.08 18:51
Ach das bekomm ich hin.
Timosch - So 17.08.08 18:54
Ach ja, und es heißt Indizierungsdienst. Nicht, dass du dich wunderst, wenn eine Google-Suche nichts ergibt oder so...
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!