C# xEcute - der smarte Programmstarter

[Grantig]

Japp. Das hängt aber an der Komponente an sich. Ich finde das Verhalten auch etwas komisch, kann es aber leider nicht beeinflussen.

Benutzt du eigentlich Visual Studio C# als IDE? Wenn ja, dann könntest du statt den Komponenten die du jetzt benutzt auch einfach ne ListBox nehmen.

Weisst du noch welche Einstellung du verändert hast?

Ich hab mp3 als Dateiendung hinzugefügt und meinen Userordner zu den Indexierten Orten. Und den Hotkey hab ich auf Win + S umgestellt.

Japp hab ich. Ist auch gewollt so, denn ich kann nicht einen Index neu aufbauen auf den ich gerade zugreife.. Das könnte schnell schief gehen, deshalb liegt auf dem Dicitionary ein Lock bis die Indexierung fertig ist.

Naja, aber du musst ja das Dictionary nicht die ganze Zeit für die Indexierung locken.
Imo wäre es besser, wenn der Indexthread nur alle 5 - 10 Sekunden das Dictionary für nen Zugriff lockt und dann einfach alle Dateien die in dieser Zeit gefunden wurden ins Dictionary schiebt.

Ich hab da sogar mal ne Komponente geschrieben, um Dateilisten aufzubauen. Darin ist so eine Funktionalität schon eingebaut. Falls du die Komponente für dein Projekt benutzen willst, sag bescheid

Hast du neue Dateiendungen hinzugefügt? Ich hab alle möglichen Endungen ausprobiert und hatte bei der Endung *.png bei genau einer Datei immer ein Problem. Ich bin mir aber sicher dass das Problem nicht an xEcute liegt, sondern am Dateisystem, allerdings in meinem Fall. Wenn du mir deine Einstellungen sagst, versuch ichs zu reproduzieren.

Jap, mp3. Aber an meinem Dateisystem liegts glaub ich nicht, denn MS SyncToy und mein eigener FileListBuilder können meine mp3's Problemlos einlesen.

 

[Firestorm-]

Benutzt du eigentlich Visual Studio C# als IDE? Wenn ja, dann könntest du statt den Komponenten die du jetzt benutzt auch einfach ne ListBox nehmen.

Japp tu ich. Ist auch gerade eine ListBox im Einsatz, allerdings eine erweiterte Variante, da ich noch ein wenig mehr Funktionalität benötige.

Ich hab mp3 als Dateiendung hinzugefügt und meinen Userordner zu den Indexierten Orten. Und den Hotkey hab ich auf Win + S umgestellt.

Komisch.. Hab das ebenfalls nun mehrer Male versucht und konnte den Fehler nicht reproduzieren..

Naja, aber du musst ja das Dictionary nicht die ganze Zeit für die Indexierung locken.
Imo wäre es besser, wenn der Indexthread nur alle 5 - 10 Sekunden das Dictionary für nen Zugriff lockt und dann einfach alle Dateien die in dieser Zeit gefunden wurden ins Dictionary schiebt.

Da stimme ich dir zu.. Wie regelt deine Komponente das Caching der Daten? Evtl. wäre das interessant.

 

[Grantig]

Die gefundenen Dateien (bzw. die FileInfo Objekte) werden einfach in ner Liste gespeichert.
Die Komponente bietet ein ListProgressCahngedEvent an, dass:

a) bei jeder gefundenen Datei aufgerufen wird
--> In den EventArgs wird nur ein FielInfo Objekt übergeben
oder
b) immer in einem bestimmten Intervall aufgerufen wird
--> In den EventArgs werden alle FileInfo Objekte übergeben, die in dem jeweiligen Intervall gefunden wurden.

Die Events werden immer in dem Thread gefeuert, der die Komponente instanziert hat, also brauchst du dir über CrossThreadExceptions keine Gedanken machen.
Wenn die Dateisuche fertig ist, wird ein FileListCompletedEvent ausgelöst, bei dem die gesamte Dateiliste in den EventArgs übergeben wird.

 

[Firestorm-]

Hab gerade die verbesserte Version hochgeladen. Waren noch ein paar andere Kleinigkeiten drin...

Die Indexierung hab ich komplett umgebaut, allerdings nach wie vor ohne FileInfo-Objekte, aus Performancegründen.

Der Fehler bei der Indexierung sollte nun auch weg sein, genauso wie der Fehler beim Ändern von Settings und anschl. erneutem Öffnen der Settings. Du darfst wieder testen, Grantig!

 

[Grantig]

Habs mal ausprobiert. Also Exceptions werden keine mehr geworfen, aber beim mp3 indexieren stürzt es immernoch kommentarlos ab.
Und die Listboxes sind wirklich die Hölle. Es dauert manchmal fast ne Minute, bis ein Eintrag hinzugefügt ist. Was machen denn die Listbox Controls so besonderes, das es so lang dauert? Bzw. Welchen Vorteil gegenüber ner "normalen" Listbox haben die Dinger?

Außerdem habe ich versucht den Standard Hokey zu ändern, aber es wurde nicht übernommen. Als ich dann den Einstellungen Dialog wieder aufgerufen hab, waren in der Hotkey Listbox alle Einträge doppelt.
Irgendwie hab ich es bis jetzt noch nicht hinbekommen, dass xEcute überhaupt richtig funktioniert.

Für jede Datei FileInfo Objekte zu erstellen ist natürlich langsamer, meine Komponente ist auch eigentlich dafür gedacht Dateilisten mit möglichst vielen Dateiinformationen zu erstellen.
In deinem Fall wäre das evtl. nützlich, weil du dadurch auch Dateien nach Größe, Änderungs/Erstellzeitpunkt, Attributen usw. suchen könntest.
Da die Indexierung eh in nem anderen Thread ist, dachte ich ist die Performance eher sekundär, da der Index ja eh inkrementell erstellt wird (zumindest im Optimalfall).

Ich hab mal ein kleines Schema gebastelt, wie du dein Programm strukturieren könntest, damit ein guter Kompromiss aus Performance beim Indexieren und einer guten User Experience gewährleistet ist:

Ist jetzt natürlich sehr grob und sieht auch nicht besonders gut aus (zu meiner Entschuldigung: habs mit Paint gemacht ) aber imo wäre das ein gutes Grundgerüst und du würdest damit näher an die imo wirklich gute Windows (7) Suche rankommen, mit dem Bonus, dass xEcute einfacher zu Verwalten ist und noch viele weitere nützliche Features bietet.

 

[Firestorm-]

Komisch.. Also ich kann mittlerweile alles indexieren, ohne Abstürze. Selbst wenn ich mein komplettes C: Laufwerk im Index halte, gibt es keine Probleme.

Ja die Listboxen werde ich bei Gelegenheit kicken. Mir wird das Verhalten auch ein wenig zu strange. Intern hängt da wohl an der Aktualisierung ein MouseListener, da die Komponente bei anschließender Mausbewegung aktualisiert wird. Find ich mal richtig komisch...

Beim Hotkey ändern hab ich wohl noch etwas vergessen, ja. Werde es bei Gelegenheit ändern.

Danke für das Schema. Die Strukur ist bereits sehr ähnlich, bis auf den entscheidenen Unterschied: Die Datenbank. Ich denke diese wird auch nicht zum Einsatz kommen, da ich immer noch denke dass eine Daba Query, egal ob mit LINQ oder SQL einfach zu wenig performant ist, egal ob eigener Thread oder nicht...