so...tut sich schon was in punkto bugfixes & verbesserungen, oder liegt das searchtool wieder ad acta ?

0xCC hat folgendes geschrieben:

so...tut sich schon was in punkto bugfixes & verbesserungen, oder liegt das searchtool wieder ad acta ?

Tut sich schon. Das war für heute nach der Schule pelant (hab die Demo wieder auf VST geändert, da TD sowieso die Shellkompos nicht hat und ich ein Ersatz dafür brauchte). Ich war jetzt nur eine Woche nicht da (Ferien) und hab noch eine Änderung an meinem AbiForum durchgeführt, wes wegen ich nicht zum Test auf Win98 kam. Es könnte also sein, dass ichs heute schaffe. Bis zum Ende der Woche sollte ich es aber spätestens schaffen.

So ich hab mal die neue Version hochgeladen (Änderungen etc. siehe erste Seite).
@0xCC: Hättest mich ruhig noch einmal erinnern können, denn am 17. oder so war die Unit fertig getestet etc. (hatte es nur vergessen hier hochzuladen, da ich da an meinem altem Rechner war) .

Im Prinzip hat es wirklich an der Demo gelegen, dass es so lange brauchte. Denn dadurch das ich nicht mehr D2005 nehme, sondern jetzt nur noch ausschließlich TD, musste ich die Demo umschreiben, da die ShellKompos bei TD nicht dabei sind. Von daher verwendet die Demo jetzt wieder VirtualStringTree, da der Explorer, den ich dort habe, auch darauf basiert (bei der neuen Explorerkomponente hatte ich das Problem, den Begriff "Arbeitsplatz" mir zurückgeben zu lassen, was ich aber auch demonstrieren wollte).

Was mich noch interessieren würde ist, wie meine Unit mit HArdlinks umgeht. Denn solche habe ich bei mir nicht auf der Platte zum testen .

also ich bleibe bei einer simplen recursiven dateisuche - das tool ist mir viel zu groß

moddin hat folgendes geschrieben:

also ich bleibe bei einer simplen recursiven dateisuche - das tool ist mir viel zu groß

Zu groß ist gut. Die Threads blähen das soweit auf (durch die ganzen Getter und Setter). Ansonsten geht es nicht wesentlich kürzer, wenn du UniCode-Unterstützung besitzen willst, denn für Win98 und XP muss man eine Unterscheidung machen.

Letzt endlich ist deine Entscheidung, auch wenn dir einiges dabie an Komfort entgeht . Zum einem hängt in der Zeit des Suchens die GUI nicht, vor allem funktionieren dadurch die allgemeinen GUI Sachen noch, wie neuzeichnen und vergrößern, minimieren etc., und zum anderem brauchst du dich um nichts groß kümmern. Threads, vollständige Win-Kompatibilität und all so ein Zeug bekommst du schon geliefert.

Und groß ist es nun wirklich nicht. Vlt. scheinbar Zeilenaufwändig, aber ansionsten ist es nicht groß. Eigentlich wollte ich noch ein paar Filter einbauen, aber da muss ich erst gucken, denn wenn ich MSDN richtig verstanden habe, sind die Zeitstempel vom OS (oder war es Dateisystem?) abhängig, wie die formatiert zurückkommen. also potential zum Ausbauen gibt es noch genug .

hm, bietet sich dann nicht irgendwie sowas in einer Art Pluginsystem an (etwas einfacher vllcht)
Je nachdem, was für Ideen du noch hast

Gruß
alias5000

Pluginsystem wäre ein bissl übertrieben . Aber ich habe schon überlegt, für den Filter eine Schnittstelle zu schaffen, also das jeder einen eigenen Filter schreiben kann. Als Alternative bieten sich Compilierschalter an .

So es gibt jetzte V3.0.1, nachdem mich Gausi vorhin auf eine Kleinigkeit aufmerksam gemacht hat.

Und zwar wollte Gausi eine Warteschlange aufbauen und hat dazu im STFinish-Ereignis eine neue Suche gestartet. Da aber SearchTool noch darauf gewartet hat, dass er aus STFinish zurückgehrt (SendMessage), führt das zu einem Deadlock, da ja die Suche erst gestartet wird, wenn die alte beendet wurde. Bei PostMessage (Systemnachricht) trat der Fall nicht auf. Allgemein dürften Deadlocks nur auftreten, wenn in einem SendMessage-Ereignis eine neue Suche gestartet wird.
Da dies ein Fall war den ich von Seitens ST verhindern kann, allerdings nur bei STFinish und nicht beim STStart, habe ich das jetzt behoben. Freigeben kann man im ST im STFinsih trotzdem nicht .

Version 3.0.1:

• Hat man im ST-Finishereignis (SendMessage) die Suche gestartet, so endete das in einem Deadlock

//EDIT: Dafür gibt es keine extra Demo, da die Demos vom Fehler nicht betroffen sind .

Mal was ganz anderes: kannst du deine Unit nicht systemunabhängiger machen bzw. eine Linuxversion dafür auch noch machen ? Ich könnte das zwar, aber bis ich mich eingearbeitet habe, bist du schon längst fertig .

Mhm, sieht schlecht aus. Ich habe kein Linux (entweder hat Linux ne Allergie gegen meinen Rechner oder mein Rechner gegen Linux ). Von daher baue ich das nicht ein. Das ist aber nur ein Grund. Wenn ich das für Linux machen wöllte, müsste ich die Unit im Prinzip neu schreiben, da fast alles auf WinAPI basiert, und das bissl Klebemittel dazwischen ist vernachlässigbar .

Hallo,

seit ein paar Tagen spiele ich mit dem Gedanken mal eine Art Umfrage hier zu machen, was eure Erfahrungen mit der Unit sind und wo ihr Probleme etc. festgestellt habt. Die WAK betreffen natürlich auch die Demo, denn als Entwickler sieht man einige Dinge einfacher, als es sie für "Fremdlinge" sind. Von daher wäre ich echt erfreut, wenn ihr Vorschläge zur Verbesserung der Demo bzw. der Unit macht.

Des weiteren werde ich in den ersten Posts eine Auflistung an Features, die ich für die zukünftigen Versionen geplant habe (sobald ich mal wieder Zeit habe, mache ich auch an der Unit wieder etwas ).

Und noch eine Kleinigkeit: um andere Demos der Unit zu haben, habe ich mir überlegt, auch im ersten Beitrag einer Auflistung der Programme zu machen, die SearchTool nutzen - sprich damit man auch Demos hat, wo es in der Wirklichkeit angewendet wird (man findet dazu im DF meistens auch genug Gegenbeispiele, wo sie nicht verwendet wird ). Falls ihr ein Projekt habt, wo ihr dien Unit nutzt und das Proggi bereits public gemacht habt, postet hier einfach mal .

PS: Ich bin mal echt gespannt, was die Unit nach V3.0 für ein Feedback bekommt .

Grüße
Heiko

Ich versuche schon längere Zeit, irgendeine der Demos zum Laufen zu kriegen, aber der ganze sche*** mit den zusätzlichen Komponenten funktioniert bei mir nicht!!!!!
Ich habe Delphi 2007.
Installiert habe ich:

EasyListviewSetup.exe
MustangPeakCommonLib.exe
VirtualShellToolsSetup2.0.exe
VirtualTreeviewSetup.exe

WAS NUN ???

Hallo hathor,

hast du schon mal probiert ob die Virtual TreeVies Demos funktionieren (selbstkompiliert)? Wenn nicht, kann ich dir da leider nicht helfen (ich glaube nicht, dass es an der fehlenden TNT-Unit fehlt, denn soweit ich gesehen habe funzt das auch ohne).
Früher waren die Demos ohne den extra Kompos, aber seit ich D10 nutze und nicht mehr D9, geht das leider nicht mehr (hab keinen Explorer).

Falls D11 wieder die Standardmäßigen ShellKompos dabei hat, findeste ne ältere Demo dazu hier

Grüße
Heiko

Kannst du nicht einfach eine Version schreiben, die keine Fremdkomponenten verwendet!?

Wie bereits im letzten Post gesagt, gibt es für die Alpha eine Version ohne Fremdkompo (bis D9 waren die ShellTools ja noch dabei ). Bei neueren Versionen habt ihr die Wahl zwischem dem Installieren der Kompos (was sich empfiehlt um nicht woanders wieder Performanceverluste zu haben) oder die Demo von der Alpha zu nehmen und dort die ShellKompo wegzunehmen und dafür einen Edit hinlegen, in dem man den Pfad angibt. Mehr ist das IMHO nit zu machen. Und ich glaub, die alpha ist voll komatibel zur 3.0.1.

Hallo,

eine neue Version ist erhältlich. Sie enthält einen kleinen "Bugfix" (die eine CriticalSection war sinnlos).


Des weiteren findet ihr jetzte den Demo-Source im ersten Posts inkl. einer Demo, die nur die Standardkompos verwendet!

Grüße
Heiko