Filedup 1.0.7.0 - Identische Dateien finden

[calculon]

Zitat:

Zitat von bigg

Dann hat das Programm richtige Ergebnisse geliefert?

Ja, das hat es!
Wie gesagt dachte ich zunächst, dass die zwölf Dateien sich nur ähnlich sind, weil die JPGs nur eine "Tiefe" von 0.6 mm haben. Aber ich hatte es nicht überprüft. Bei näherer Untersuchung hat sich dann herausgestellt, dass sie alle einfach identisch schwarz sind. Wieso das so ist, weiß ich auch nicht. Aber das zeigt, dass "Filedup" auch solche Phänomene entdecken kann.

Gruß

Calculon
--

[toms]

Zitat:

Zitat von xZise

Vorschlag: Einen pausieren Möglichkeit ;)

wäre auch dafür!

[idontwantaname]

Hab auch gerade dein Programm getestet und ich muss schon sagen: echt super gelungen :thumb:

Hattet ihr schon mal in 51.377 Dateien 18.145 Duplikate? :mrgreen:

[yankee]

Soweit ich das sehe verwendest du keine Threads...

Wenn du mehrere Dateien gleichzeitig in Threads analysieren würdest, könntest du bestimmt nochwas mehr Geschwindigkeit aus dem prog rausholen.
Besonders Leute mit Hyperthreading oder MultiCore-CPUs dürften einen kräftigen Performancegewinn erwarten, aber auch mit anderen CPUs daürfte es schneller laufen... Zumindest etwas.

[himitsu]

mehrere Dateien gleichzeitig bring in diesem Fall kaum etwas, da der Flaschenhals ja bei der Festplatte liegt und wenn dort dann an nochmehr Stellen gleichzeitig gearbeitet wird, dann wird eher alles noch Langsamer, wegen dem vielen Hinunhergespringe :zwinker: http://fnse.de/S05/1OC.gif

Ach ja ... bei wenigen Dateien und kleinen Datenmengen ist dein Programm zusammen mit der FileCache natürlich recht "schnell", aber bei besonders vielen und/oder großen Dateien wird die WindowsFileCache schon mal recht schnell überlastet und beginnt dramatisch dat Programm auszubremsen, weßhalb dort NonCached von Vorteil ist.

PS: darum sind ja eigentlich die CPU-Angaben recht uninteresant (die CPU-Last des Programms ist eh recht gering ... war bei der ersten Version ja noch nicht so ... hatte sie gerade nochmal mit im Vergleich )

http://fnse.de/S05/1O7.gif



PSS:
mein kleines Vergleichsprojektchen, welches sich jetzt am 3. Entwicklungstag dem Ende meiner Aufmerksamkeit entgegensieht, schaut nun so aus ... jetzt auch mit SourceCode :angel:

- mehrere Suchverzeichnisse möglich (einfach mit * trennen)
- Drag&Drop (auch mit mehreren Verzeichnissen)
- unicodefähig (wenn TEdit und TLabel entsprechend ersetzt werden)

- DIE CHECKBOX... (bevor sich wer wundert)
Damit wird das "ECHTE" Löschen der Dateien übergangen.
Die Dateien werden also nur in der List gelöscht und nicht in Echt, wenn da ein Häckchen ist.


Der 2. Hash (TopHash) ... früher (wenn man gestern so nennen darf) mal der Hash der kompletten Datei (FullHash) ... kann mit folgenden 2 Zeilen übergangen werden.
(eventuell wird er eh bald komplett entfernt)

Delphi-Quellcode:

// mit zweitem Hash
Function GetTopHash(Dir: Integer; Const Name: WideString): TCRC32o;
  ...

  Begin
    D := '';

// OHNE zweiten Hash
Function GetTopHash(Dir: Integer; Const Name: WideString): TCRC32o;
  ...

  Begin
Result := $12345678;
Exit;
    D := '';

[xZise]

Vorschlag (wenn es himitsu zulässt :D):
Mache während er sucht eine "Schafanimation" ;) Oder du lässt eine Lupe über das Schaf kreisen :D

Aber trotzdem muss ich sagen: Das Desgin des Programms wirkt sehr "fachmännisch" ;)

[edit]Ich konnts net lassen :D Und ich habe jetzt mit dem Schaf und einer Googlelupe, das ultimative "SchafSearch"-Bild erstellt :D
Ich habe es mit GIMP erstellt. Ich stelle hier mal folgende Varianten vor:

• Große Animation (400 x 400px) in Gif
• Kleine Animation (40 x 40 px) in Gif
• Die große Animation in .xcf (Gimp-Format) in 3 Variantionen
  • Nur das Schaf
  • Animation mit je 2 verschiedenen Ebenen pro Frame
  • Animation mit einer Ebene pro Frame = Endprodukt

[yankee]

Zitat:

Zitat von himitsu

~480.000 Dateien (mit irgendwas über 130 GB)
WinXP SP2 Athlon64 3000+
nach 2,5 Stunden bei etwa 20% abgebrochen

ääähhhmmm...
333.337 Dateien,
~216 GB
Win2k SP4 Rollup1
2x250 GB HDD, Raid 0
Bei 25% Bin ich bei ca. 17 Minuten und 30 Sekunden...

Zitat:

Zitat von himitsu

mehrere Dateien gleichzeitig bring in diesem Fall kaum etwas, da der Flaschenhals ja bei der Festplatte liegt und wenn dort dann an nochmehr Stellen gleichzeitig gearbeitet wird, dann wird eher alles noch Langsamer, wegen dem vielen Hinunhergespringe

Stimmt wohl... :-(.

Aber apropos... FindAllFiles ist sehr langsam...
Der FileScavenger braucht nur 12 Sekunden um von meinen Platten alle Dateien in eine Liste zu schmeissen. Und das bei wenig gerödele.
Und FileDub braucht *mess* ... .. moment.... das hat doch eben viel länger gedauert. Kann doch nicht sein, dass der jetzt in 6 Sekunden fertig ist... Und das fast ohne auf die Festplatte zuzugreifen??? Wie kann das denn jetzt sein? Mal abgesehen davon findet der jetzt auf einemal mehr als 200 Dateien mehr (wo kommen die denn her?).

Also eigentlich wollte ich nur sagen, dass es bestimmt schneller geht direkt auf der Festplatte zu suchen statt die WinAPI zu nehmen. Allerdings weiss ich natürlich nicht, wie einfach sowas ist, und wenn man nur in einem Verzeichnis, statt auf der ganzen Platte sucht, ist das wahrscheinlich sowieso wieder hinfällig...

P.S.: Kannst du die Einstellungen noch woanders als in der Registry speichern? Das ist echt total unnötig, dass da so ein programm, welches man alle Jubeljahre mal verwendet seine Fenstergrösse 24/7 im RAM hat...
Bei Programmen, die ich häufiger nutze sehe ich das genauso, aber bei sowas kleinem ganz besonders...
Ausserdem solltest du dann wneigstens einen uninstaller mitbringen, der die Einträge wieder löscht...

[bigg]

moin moin,

Zitat:

Zitat von yankee

Aber apropos... FindAllFiles ist sehr langsam...
Der FileScavenger braucht nur 12 Sekunden um von meinen Platten alle Dateien in eine Liste zu schmeissen. Und das bei wenig gerödele.
Und FileDub braucht *mess* ... .. moment.... das hat doch eben viel länger gedauert. Kann doch nicht sein, dass der jetzt in 6 Sekunden fertig ist... Und das fast ohne auf die Festplatte zuzugreifen??? Wie kann das denn jetzt sein? Mal abgesehen davon findet der jetzt auf einemal mehr als 200 Dateien mehr (wo kommen die denn her?).

kann schon sein, das es schneller ist. Es könnte auch gut möglich sein, das das von dir genannte Tool die Dateizuordnungstabellen ausliest, und somit natürlich schneller wäre. Das die Ergebnisse so unterschiedlich ausfallen, liegt vermutlich am Cache von XP. Wenn die gefundenen Daten schon im Cache liegen, gehts natürlich wesentlich schneller. Um es richtig zu testen, müßtest du Windows mal runterfahren und beide Programme unabhängig von einander testen.

Zum Thema Threads:

Zitat:

Zitat von yankee

Soweit ich das sehe verwendest du keine Threads...

Doch, ob du's glaubst oder nicht ich verwende wirklich Threads, aber nur den Hauptthread der Anwendung. :mrgreen:
Außerdem hat himitsu schon alles weitere gesagt... :mrgreen:

Zum Thema Registry:
Ich werde noch eine Funktion integrieren, die beim ersten Start von Filedup fragt, wohin die Einstellungen gespeichert werden sollen oder einen Parameter anbieten, der die Lade- und Speicherfunktionen überspringt, mal schaun, was da besser ist.

@XZise:
Hab mir die Bilder angesehen, ist schon abgefahren das ganze..., wenn ihr mir garantieren könnt, das mir dafür niemand die tür einrennt, baue ich es selbstverständlich ein. :stupid:

@dj_base: Ich arbeite schon seit Anfang Dezember 2006 an einer echten 2ten Version von Codepad, die dann auch Unicode unterstützen wird.

PS: Päuschen und Exportoptionen sind schon fast anwendungstauglich, denke das ich es heute noch hochstelle...

[xZise]

Wäre es möglich, dass man das Programm beendet, und nach einen neuen Start "weitersucht"?

Weil beim ersten mal musste ich es abbrechen, weil es zu lange dauerte ;)

PS: Wie überprüfst du eigentlich nach doubletten? Ich hoffe doch zuerst die Dateigröße ;D

[bigg]

So, eine neue Version ist oben, die die folgenden Änderungen beinhaltet:

1.0.4.0
- Pause-Schaltfläche der Statusanzeige hinzugefügt
- Formular 'Optionen' unter Ansicht abrufbar
- Optionen für den Export integriert
- Einstellungen können dauerhaft gesichert werden

Zitat:

Zitat von XZise

Wäre es möglich, dass man das Programm beendet, und nach einen neuen Start "weitersucht"?

Jupp, wäre möglich, dennoch fehlt mir im Moment die Zeit und Lust. Viel wichtiger wäre es, den Suchprozess zu optimieren, dann könnte man sich das gleich sparen.^^

Zitat:

Zitat von XZise

PS: Wie überprüfst du eigentlich nach doubletten? Ich hoffe doch zuerst die Dateigröße ;D

Da müsste ich erst im Quelltext blättern, und nen bissle suchen. :gruebel: :wall:

[himitsu]

Also dat versteh ich nicht ganz, :gruebel:
wieso übergibst du die Zeit SetStateTime(Project.CurrentTime);,
wenn du sie eh nicht verwendest?

Delphi-Quellcode:

procedure TStatusForm.SetStateTime(const Seconds: Cardinal);
begin
  TimeLabelContent.Caption := SecondsToHours(Project.CurrentTime);
end;

so wird's wohl gemeint sein.

Delphi-Quellcode:

procedure TStatusForm.SetStateTime(const Seconds: Cardinal);
begin
  TimeLabelContent.Caption := SecondsToHours(Seconds);
end;

Dann ist diese voll mißt, denn es zählt total falsch.
Nach dem oben schon erwähntem Szenario benötigt mein Programm 2,2 Stunden und deines hab ich nach über 2 stunden bei 11% abgebrochen, jedoch hatte es seiner Meinung nach bis dahin nur 1,5 Stunden gebraucht.
Im Extem gingen schonal in nur 30 Sekunden über 10 Sekunden auf deiner Uhr verloren. :shock:

Da OnTime durchschnittlich nicht alle genau einer Sekunde aufgerufen wird (ist bei deinem Programmaufbau garnicht möglich) muß falsch gezählt werden,
da zwar nach spätestens 1 Sekunde durch den Timer der Aufruf von TStatusForm.OnTime veranlaßt wird, aber durch die eher sperrliche Abarbeitung der Nachrichtenliste deiner Anwendung Einiges untergeht und verzerrt wird.
Es wird ja nur wärend Application.ProcessMessages die Nachrichtenliste abgearbeitet

> siehe TimeDemo (Anhang)
Da läuft ein Timer mit 100ms-Intervall.
Als Versuchswerte bieten sich 0, 50, 100 und 500 an:
- 0 und 50: zu vermuten wäre, daß wegen des geringeren Intervalls die Zeit fast genau wäre, dennoch fehlt Einiges.
- 100: hier könnte man auch 'ne Übereinstimmung vermuten, da beide Intervalls gleich sind.
- über 100 (Timer1.Intervall = 100) muß was fehlen, da hier das Intervall zu groß ist und dadurch auf Jedenfall die Nachrichtenverarbeitung verschleppt wird.


Besser du speicherst die Startzeit und rechnest die tatsächlich vergangene Zeit aus.
(GetTickCount + Integer-Cardinal-Konvertierung sollte hoffentlich mit den bis zu 24,86 Tagen ausreichen)

Delphi-Quellcode:

procedure TStatusForm.OnTime(Sender: TObject);
begin
  SetStateTime(GetTickCount - Project.CurrentTime);
end;

procedure TStatusForm.InitStateTime;
begin
  Project.CurrentTime := GetTickCount;
  SetStateTime(GetTickCount - Project.CurrentTime);
end;

Vergiß aber nicht die vergangene Zeit nach Scanende zu speichern (für deine Statistik).



Wenn ich die Laufzeit bei mir so sehe, dann wäre es nett, wenn man zwischen Cached- und NonCached-Dateioperationen auswählen könnte.
Vorallem ist es Schlimm, wenn nachdem (und natürlich auch wärend) dein Programm lief, alles was auf die Festplatte zugreift teilweise minutenlang braucht ... vorallem ganz nett im Explorer anzusehen ... is hier aber auch kein Wunder, denn schließlich braucht es 'ne kleine Weile, bis so 700-800 MB aus der Systemcache abgebaut und aufgeräumt wurden ... zum Glück paßt da bei mir zur Zeit nicht nochmehr rein ^^

Zitat:

Da müsste ich erst im Quelltext blättern, und nen bissle suchen

ich dachte man weiß in etwa, was man verbrockt hat :gruebel:

aber keine Sorge ... ich seh in deinem Quellcode och nicht so ganz durch ... anderer Codestil und total andere (mir unverständliche) Herangehensweise... :angel:




PS:
458.714 - 170 GB
164.051 - 9,45 GB


PSS: http://www.delphipraxis.net/internal...=663073#663073


Und dat Schaf:
ich liebe es ... is ja auch mein Sternzeichen (jap) :zwinker:

http://fnse.de/S05/1O6.gif http://fnse.de/S05/1O7.gif http://fnse.de/S05/1OA.gif http://fnse.de/S05/1OB.gif http://fnse.de/S05/1O8.gif http://fnse.de/S05/1OD.gif http://fnse.de/S05/1O9.gif http://fnse.de/S05/1OC.gif

Bin zwar nicht der Copyrightinhaber davon, allerding sollte es keine rechtlichen Probleme geben.
werd' aber bei Gelegenheit bei Natasja nochmal anfragen.

[xZise]

Zitat:

Zitat von bigg

Zitat:

Zitat von XZise

Wäre es möglich, dass man das Programm beendet, und nach einen neuen Start "weitersucht"?

Jupp, wäre möglich, dennoch fehlt mir im Moment die Zeit und Lust. Viel wichtiger wäre es, den Suchprozess zu optimieren, dann könnte man sich das gleich sparen.^^

Da wäre ich mir nicht sicher :D Ich habe länger als 2 Stunden gebraucht ;)
Du müsstest also sehr viel raushauen, um da wirklich die Pause zu sparen :D

[bigg]

Naja, solchen Käse verzapft doch jeder mal... :wink:

Delphi-Quellcode:

  Function SizeToString(Size: LargeInt): String;
    Var i: LargeInt;

    Begin
      i := Abs(Size);
      If i < 1000 Then Result := Format('%.0n B', [Size / 1])
      Else If i < 10235 Then Result := Format('%.2n KB', [Size / 1024])
      Else If i < 102349 Then Result := Format('%.1n KB', [Size / 1024])
      Else If i < 1023488 Then Result := Format('%.0n KB', [Size / 1024])
      Else If i < 10480518 Then Result := Format('%.2n MB', [Size / 1048576])
      Else If i < 104805172 Then Result := Format('%.1n MB', [Size / 1048576])
      Else If i < 1048051712 Then Result := Format('%.0n MB', [Size / 1048576])
      Else If i < 10732049531 Then Result := Format('%.2n GB', [Size / 1073741824])
      Else If i < 107320495309 Then Result := Format('%.1n GB', [Size / 1073741824])
      Else If i < 1073204953088 Then Result := Format('%.0n GB', [Size / 1073741824])
      Else If i < 10989618719622 Then Result := Format('%.2n TB', [Size / 1099511627776])
      Else If i < 109896187196212 Then Result := Format('%.1n TB', [Size / 1099511627776])
      Else If i < 1098961871962112 Then Result := Format('%.0n TB', [Size / 1099511627776])
      Else If i < 11253369568892027 Then Result := Format('%.2n PB', [Size / 1125899906842624])
      Else If i < 112533695688920269 Then Result := Format('%.1n PB', [Size / 1125899906842624])
      Else If i < 1125336956889202688 Then Result := Format('%.0n PB', [Size / 1125899906842624])
      Else Result := Format('%.2n EB', [Size / 1152921504606846976]);
    End;

:shock:

Recht haste aber trotzdem mit dem Counter. War im übrigen bekannt, man muss nur ein paar mal hintereinander 'Pause ' drücken, während "er" rödelt. Das ich allerdings die globale Variable dafür benutze, war nicht geplant. Haste ja rischtisch gesacht und werdsch mal ändern. :wink:

Zitat:

Zitat von himitsu

ich dachte man weiß in etwa, was man verbrockt hat Grübelnd...

aber keine Sorge ... ich seh in deinem Quellcode och nicht so ganz durch ... anderer Codestil und total andere (mir unverständliche) Herangehensweise... Angel

Hab schon schlimmeres gesehen. :mrgreen:
Aber vielleicht kann ich dir ja och noch uff de Sprünge helfen und dir einiges erklären. :stupid:

PS: Wäre schön, wenn der Copyright-Inhaber nichts dagegen hätte.

@XZise: Da geht in jedem Fall noch was. :angel2: Mein Zufallsgenerator muss nur irgendwann den richtigen Code ausk*****.

[himitsu]

upps, vergessen die Datei mit hochzuladen :wall:

Zitat:

Zitat von bigg

SizeToString...

:shock:

was dagegen?

Wert immer maximal 3-stellig und dann sind die Werte speziell auf das standardmäßige Rundungsverhalten der FPU abgestimmt.
Und ja, es ist mit Absicht mit IF und nicht über CASE gelöst :angel:


PS: Sheepo ... sie hatte so jedenfalls (soweit ich es noch weiß) nie verboten gahabt, :angel:
's is aber bestimmt auch schon über 1,5 Jahre her, dat ich die Kleinen fand.

[bigg]

moin moin,

Warum if und case verwenden, wenn es auch iterativ zu lösen ginge?
Nur der Rundung halber? :gruebel:

Delphi-Quellcode:

function FileSizeToString(const FileSize: Int64): String;
const Measure: Array[0..4] of String = ('Byte', 'KB', 'MB', 'GB', 'TB');
var NewSize: Currency;
var i: Integer;
begin
  Result := '';

  if FileSize > -1 then
  begin
    i := 0;
    NewSize := FileSize;

    while (NewSize >= 1024) do
    begin
      NewSize := NewSize / 1024;
      Inc(i);
    end;

    case i of
      0: Result := FloatToStr( NewSize );
      1,
      2,
      3: Result := FormatFloat('0.00', NewSize);
      4: Result := FormatFloat('0.000', NewSize);
    else Result := FloatToStr( NewSize );
    end;

    Result := Result + #32 + Measure[i];
  end;
end;

PS: TimeTest hab ich mir angesehen, werd ich wie gesagt nochmal fixen.
Und @alle die ihre Farben ändern, aber sich wundern, warum im Report andere Farben auftauchen, is so,
nich wundern ;>.

[himitsu]

meines bekommt keine Rundungsfehler ('s wird ja nirgends was umgerechnet), ist schneller und warum erst in 'ner Schleife mit langsamen Fließkommazahlen rechnen, wenn doch einfache Integervergleiche ausreichen :zwinker:

und deines zeigt doch bestimmt 1010 Byte als 1010 Byte an ... meines als 0,99 KB ... wie gesagt, ich wollte genau 3 Stellig haben und nicht nur meistens, oder so in etwa... :roll:

schau dir doch mal die Integer-Vergleichswerte an ... es hat 'nen Grund, dat die krum und bucklig sind (z.B. 10235 statt 10240) :mrgreen:

[bigg]

[ot]
Schau dir doch mal an, was der Windows Explorer (Datei->Eigenschaften) bei 1010 Byte anzeigt. :stupid:
Das der Datentyp Currency nur 4 Nachkommastellen aufnimmt, ist für diese Berechnung auch nicht weiter schlimm, schließlich zeige ich auch nur maximal 3 Stellen hinter dem Komma an.

Wie och immer...so hat jeder seine eigene Logik...
PS: Und ganz Explorer-Like arbeitet meine Funktion nicht...woltsch nur anmerken :warn:
[/ot]

[bigg]

moin moin,

eine neue Version ist oben und darf getestet werden.

1.0.5.0
- Optimierung der Suche
- Dauer der Suche wurde falsch berechnet
- Stop bricht nun sofort einen Suchvorgang ab
- Breiten aller Spalten (Dateiliste) werden nun gesichert
- Sortierung der Spalten 'Name', 'Verzeichnis' und 'Typ' arbeiteten nicht korrekt
- eine Zusammenfassung eines Suchlaufs kann nun in die Zwischenablage kopiert werden

[xZise]

Zu euren Größenpräfixen:
Sie brauchen für eine Berechnung von 100.000 mal ungefähr 62 ms ;) Also ist es eigentlich egal, was ihr verwendet.
(Dateigröße: 123456 Byte)

Zusätzlich habe ich noch die "Thousands"-Methode entwickelt, welche zuerst ausrechnet, welche Tausenderpotenz es hat, und das dann als Potenz nimmt zur Berechnung.
Dummerweise ist es nicht schneller :( Ganz im Gegenteil... ~ 125 ms für 100.000 Berechnungen.

PS: Ich rechne mit "GetThreadTimes"

[bigg]

moin moin,

@XZise: Beide Funktionen sind schnell genug, um die Aufgabe zu lösen. Sie werden hauptsächlich beim Zeichnen des Grids verwendet, im Endeffekt also keine 1000 aufgerufen pro Zeichnung. Somit dürfte der Zeitunterschied = 0 betragen. Darum ging es aber auch gar nicht, es ging um Programmier-Stil.

Gruss bigg

[himitsu]

Jo, schnell genug sind sie alle Male (vorallem da bei mir diese Funktion auch nur wärend der Anzeige (mindestens alle 125ms) aufegerufen wird).

Und was dein Vergleichsprogramm vermutlich vorwiegend mißt, sind die Stringoperationen ... die "schnellen" Brechnungen/Vergleiche fallen da kaum in's gewicht.

Der Hauptgrund für meine "Statik"-Methode liegt da darin, daß ich genau maximal 3-stellige Zahlen wollte und es daher Aufgrund der Auf-/Abrundungen so am "Einfachsten" ist genau die Umschaltstellen zu treffen :angel:


Dieses schaltet ja erst bei 1024 um:

Delphi-Quellcode:

while NewSize >= 1024 do begin 
  NewSize := NewSize / 1024; 
  Inc(i); 
end;

jetzt könnte man zwar auf diese Idee kommen:

Code:

while NewSize >= [color=#ff0000][b]1000[/b][/color] do begin 
  NewSize := NewSize / 1024; 
  Inc(i); 
end;

aber dieses funktioniert vorallem wegen der Aufrundung nur bis KB.

[bigg]

ich nochmal,

eben, somit lassen sich vergleiche schwer treffen, da beide Funktionen unterschiedliche ergebnisse liefern. Bei himitsu's Funktion dürften die erzeugten strings kleiner ausfallen.

[bigg]

moin,

nach längerer Durststrecke gibt es mal wieder ein Update. Dieses beinhaltet die Anzeige von Dateisymbolen in der Ergebnisansicht. Die Selektion von Dateien wurde ebenfalls optimiert, dadurch können Dateien schneller gelöscht werden. Den Suche-Dialog habe ich ebenfalls nochmal angepasst, um nicht zu sagen aufpoliert. Getestet wurde das Programm dann unter Vista RC2, XP SP2, 2000 SP4, 98 FE und Win95b.


PS: Fehlerreports und Feedback sind erwünscht, die Quellen sind nun auf meiner Seite erhältlich.



mfg

[Tommy1988]

Wo bekomme ich "Virtual-String-Tree" her ?

oder kurz:

Was muss ich alles installieren, um die Anwendung compilieren zu können?

[bigg]

Es sind lediglich 3 Komponenten die benötigt werden:

- VirtualTreeView

http://www.google.de/search?hl=de&q=...le-Suche&meta=
:wink:

- Toolbar 2000 (nur TTBImageList)
- TFolderTreeView (von Jordan Russels Inno-Setup)

[Tommy1988]

Kompilieren bei mir =

1.
Feld MainForm.ListView besitzt keine entsprechende Komponente. Soll die
Deklaration entfernt werden?

2.
Zugriffsverletzung bei:
Main.pas Reihe 235
Self.ListView.DoubleBuffered := True;

[bigg]

Hast du VirtualTreeView installiert? :wink:

[Tommy1988]

Was denn jetzt :( :( :(

Zitat:

VirtualTreeView

http://www.google.de/search?hl=de& ... e&btnG=Google-Suche&meta= <=== Virtual STRING TREE

Virtual TREE VIEW

oder

Virtul Strin Tree ?

Habe nur letzteres installiert...

[bigg]

Im Paket von VirtualTreeView ist natürlich die Komponente die du genannt hast enthalten. :wink:

[Tommy1988]

Virtual Treeview (source only)

Das habe ich installiert..

Aber das geht ja nicht.. wie oben schon steht ,. das passiert dann


Edit:

Es hat doch noch alles geklappt..
ein TIPPFEHLER (!!!!) war schuld!

[bigg]

Ganz ruhig, alles wird gut. Installiere alle 3 Komponenten-Pakete dann geht alles wie von selbst.

[Tommy1988]

Achso, da würde ich noch gerne was sagen..

dieses "dingen" wo man den Ordner auswählen konnte (EXE aus dem ZIP-Archiv)..

fand ich besser als den Dialog der jetzt da ist.. wie kann man das wieder ändern?

[Tommy1988]

Ach, nochetwas:

http://www.delphipraxis.net/download.php?id=13157

So wie es auf dem Bild ist war es hundert mal besser als aktuell im source.

da blickt doch keiner durch, finde ich..da werden dateien angezeigt, die garnicht doppelt vorhanden sind..

[bigg]

Die Funktion zum Anzeigen des alten Dialogs nannte sich SelectDirectory(). Diese befindet sich in der FileCtrl.pas. Du rufst den Dialog auf und übergibst der Funktion zum Suchen der Dateien den Pfad, fertig.

edit: Oops, also im moment blicke ich nicht mehr durch. Was ist jetzt dein Problem? Das Programm funktioniert wie so oft bewiesen oder häng hier mal einen Screenshot an, der Gegenteiliges beweist. Könnte ja durchaus sein...

edit2: Jetzt habe ich erst bemerkt was du meinst. Du rufst eine falsche Funktion auf.