Daniel's Copier - Update: 5.2.2005

[Kernel32.DLL]

Daniel's Copier ReRelease

What's that?
"DUC" dient dazu, Daten von beschädigten Datenträgern zu retten. Angenommen, ihr habt eine VCD die extrem verkratzt ist. Jetzt wollt ihr die Datei auf der CD unbedingt noch vor dem weiteren Verfall retten. Also benutzt ihr den Windows Explorer und zieht via Copy&Paste die Datei auf den Rechner.
So weit, so gut. Jetzt kann es aber passieren, dass der Windows Explorer auf Grund der beschädigten Datenstruktur sich weigert, die Datei zu kopieren. Es kann auch passieren, dass sich das komplette System aufhängt.

Ja, und?
"DUC" ist anders. Das Programm kopiert ohne zu murren eine beschädigte Datei. Sollten die aktuellen Bytes partout nicht lesbar sein, wird einfach weitergesprungen.


Noch was:

Je nachdem, wie beschädigt die CD und wie gut euer Laufwerk ist, kann dieser Vorgang mehrere Stunden dauern...

Der Fairness halber verweise ich noch auf das Programm, dass Dust Signs im Delphi-Forum vorgestellt hat und denselben Dienst leistet wie meins, allerdings mit dem Unterschied, dass meins ein GUI hat, Dust Sign's hingegen eine Konsolen-App ist. Dadurch bin ich wieder auf mein Projekt gestoßen. Thx.

************************************************** ******


Nun denn, der nächste Anlauf:

Version 1.5 ReRelease

Es wurde Einiges geändert:

• Kompletter Verzicht auf die TThread-Klasse
• Kompletter Verzicht auf die Units Classes & SysUtils, dadurch ~50kb eingespart
• Den dämlichen Fehler mit den 49152 Bytes zuwenig korrigiert. (<= Fehler war echt dämlich! :wall: )
• Keine AV beim Beenden des Programmes
• Log-Liste in eigenem Fenster
  
  ToDo-Liste:
• Rekursive Dateiensuche in Ordnern, um komplette Ordnerinhalte in einem Rutsch zu kopieren. Ist bereits im QT zu finden, ist aber noch zu buggy.
• Zahl der zu lesenden Bytes von 1*1024 - 64*1024 einstellbar machen, um den User selbst entscheiden zu lassen:
  Geschwindigkeit <=> Genauigkeit

Hoff' mal, dass es jetzt besser läuft!

[Edit 0815] Kaum 10 Min. Online und schon das erste Update der neuen Version[/Edit 0815]

[MagicAndre1981]

Hi,

ich habe dein Programm getestet und 2 Fehler entdeckt.
1. Fehler: dein Programm hat nicht gestoppt als die eigentliche Dateigröße schon kopiert wurde. Es hat meine Datei größer gemacht als sie eigentlich war (siehe Anhang, links das Ergebnis, rechts das original). Ich habe den Kopiervorgang dann einfach abgebrochen.
2. Fehler: Wenn man während des Kopiervorgangs auf den Kopierenbottun klickt werden alle Icons in der Liste zu dem error icon umgeändert.

Aber sonst ist dein Programm genau das, was ich gesucht habe.

Gruß

[Kernel32.DLL]

Zitat:

Zitat von MagicAndre1981

1. Fehler: dein Programm hat nicht gestoppt als die eigentliche Dateigröße schon kopiert wurde. Es hat meine Datei größer gemacht als sie eigentlich war (siehe Anhang, links das Ergebnis, rechts das original). Ich habe den Kopiervorgang dann einfach abgebrochen.

Verdammt, das sollte natürlich nicht so sein. Werde mich ransetzen.

Zitat:

Zitat von MagicAndre1981

2. Fehler: Wenn man während des Kopiervorgangs auf den Kopierenbottun klickt werden alle Icons in der Liste zu dem error icon umgeändert.

Das meinte ich mit:

Zitat:

ToDO-Liste:
[...]
-Extreme Probleme mit HIMAGELIST

Weiß nocht nicht hundertpro, wie ich das gefixt bekomme...

Daniel

[Kernel32.DLL]

So, kleiner Hotfix => siehe 1. Beitrag

Jetzt weiß ich, was der Button "Neue Version hochladen" soll :wall:

[MagicAndre1981]

Hi,

das Programm arbeitet jetzt bis auf das Iconproblem korrekt. Frag doch wegen den Icons mal den Win32 API Freak Luckie.

Gruß

[Luckie]

Puh. "vom gut lesbar Status weit entfernt" ist gut. Noch nicht mal in der Nähe würde ich sagen. :roll: Keine Kommentare nichts. Und deine Kopier-Routine bleibt mir ein Rätsel. :gruebel:

Im Anhang die überarbeitet Version, was die Icons im Listview angeht. Um den Rest habe ich mich nicht gekümmert, bis auf die Tatsache, dass ich deine zwei Ditzend überflüssigen Variablen entfernt habe und die Warnungen behoben habe, damit ich sehe, welche warnungen und Hinweise von meinem Code verursacht werden. Dass der Compiler Hinweise und Warnungen ausgibt hat schon seinen Sinn. Und gerade Warnungen würde ich nicht unbeachtet lassen. :roll:

Delphi-Quellcode:

{*************************************************************

  Luckie:
  So habe mal etwas geändert und verbessert.

  1.) Prozedur MakeColumns für die Spalte vom Listview.
  2.) Eigene Prozedur geschrieben, um Statusinformationen
      im Listview anzuzeigen (AddStatus). Deine war
      unbrauchbar. Du hast irgendwie jedes mal die Bitmaps
      wieder zur ImageList hinzugefügt oder so. Das braucht
      man nur einmal beim Erstellen der ImageListe. Siehe
      dazu Code in WM_CREATE.
      AddStatus erwartet als ersten Parameter die Status-
      meldung und als zweiten den IconIndex aus der Image-
      liste, das angezeigt werden soll. Dabei beginnt die
      Zählung bei null!
      Musst du mal gucken, ob das so passt, wie du es dir
      vorstellst.
  3.) Man sollte keine hardgecodeten Zeichenkettenkonstanten
      benutzen. Statt dessen entweder richtige Konstanten
      nehmen oder besser, falls die Anwendung mal lokalisiert
      werden muss, Resourcenstrings, diese werden in die
      Ressource einkompiliert.
  4.) Dutzende von überflüssigen Variabeln entfernt.
      (Hinweise und vorallem Warnungen spuckt der Compiler
      nicht aus, um nicht beachtet zu werden!!!)

  Sonstige Anmerkungen:
  1.) Deaktiviere die Schaltflächen, wenn sie nicht
      angeklickt werden sollen / dürfen. Ist anwender-
      freundlicher und erspart dir Code, um Fehler
      abzufangen.
  2.) Existiert die zu kopierende Datei nicht, bekommst du
      hier:
      j := x * 100 div GetFileSize(source);
      eine Exception. Prüf vorher, ob die Datei existiert
  3.) Wo wird hinkopiert, wenn das Verzeichnis nicht
      existiert?
  4.) In der Execute Methode deines Threads fehlt jegliche
      Fehlerbehandlung.
      Es wird nicht geprüft, ob die Datei oder das
      Zielverzeichnis existiert.
      Es werden nur schön Statusmeldungen ausgegeben, wenn
      etwas geklappt hat, aber was wird ausgegeben, wenn
      was schief gelaufen ist? Nichts.
  5.) Dein Thread wird nie terminiert. Daher ist ein
      zweiter Kopiervorgang nie möglich. Selbst das Klicken
      auf "Abbrechen" terminiert anscheinend den Thread nicht.
  6.) Es gibt immer eine schöne AccessViolation beim
      Beenden. Darum habe ich mich aber jetzt nicht
      gekümmert.
  7.) Bei jeder Datei, die ich kopiert habe konnten 49152
      Bytes angeblich nicht gelesen und kopiert werden.
  8.) Die kopierte Datei ist größer, als die ursprüngliche
      Quelldatei?!? Wie kannst du mehr kopieren, als
      vorhanden ist?
  9.) Warum nonVCL, wenn du die Dickemacher (SysUtils, Classes)
      doch benutzt?
      Wenn ich deinen Kopier-Code verstehen würde, würde
      ich mal eben ein Version ohne die TThread-Klasse
      machen.
  10.) Übergib dem Thread Quelldatei und Zielverzeichnis
       als Paramter und hol sie nicht in der Execute
       Methode aus den Edits.


*************************************************************}

Änderungen von mir im Code sind mit

Delphi-Quellcode:

// Luckie

gekennzeichnet. Das steht immer über der Änderung. Ganze Prozeduren habe ich mit einem Prozedur-Header versehen.

[Garfield]

Zitat:

Zitat von Kernel32.DLL

Daniel's Unstoppable Copier PreRelease

Die Konkurrenz für http://www.roadkil.net/unstopcp.html :-D

Zitat:

Zitat von Kernel32.DLL

... Angenommen, ihr habt eine VCD die extrem verkratzt ist. ...

... Sollten die aktuellen Bytes partout nicht lesbar sein, wird einfach weitergesprungen.

Werden MPEGs nicht paketweise gelesen? Dann müssten die fehlenden Bytes doch aufgefüllt werden.

[Kernel32.DLL]

@Luckie: Ziemlich vernichtendes Urteil. Werde mir deine Kritik zu Herzen nehmen. Ich komme 'grad von meinem Praktikumsplatz und sehe mir die Änderungen mal an. Danke dir.

Zitat:

Zitat von Garfield

Zitat:

Zitat von Kernel32.DLL

Daniel's Unstoppable Copier PreRelease

Die Konkurrenz für http://www.roadkil.net/unstopcp.html :-D

Verdammt, das Programm kenn ich gar nich! Muss ich jetzt den Namen meines Tools ändern?

Zitat:

Zitat von Garfield

Zitat:

Zitat von Kernel32.DLL

... Angenommen, ihr habt eine VCD die extrem verkratzt ist. ...

... Sollten die aktuellen Bytes partout nicht lesbar sein, wird einfach weitergesprungen.

Werden MPEGs nicht paketweise gelesen? Dann müssten die fehlenden Bytes doch aufgefüllt werden.

Hab' mich etwas falsch ausgedrückt. Die fehlerhaften Bytes werden natürlich ersetzt.

mfg
Daniel

[Kernel32.DLL]

also:

=> AV beim Beenden des Programms: Ich konnte den Fehler lediglich mit deiner kompillierten Version reproduzieren. Bei mir (Delphi 5 Professional) ist der Fehler mit meiner kompillierten Version nicht reprduzierbar.

=> Zeile 648:

Delphi-Quellcode:

Integer(CW_USEDEFAULT), // Luckie: Wert verletzt untere Grenze

Nö. Oder hatte das, was vorher dort stand die unteren Grenzen verletzt?

=> Warum hast du denn das hier gelöscht:

Delphi-Quellcode:

      hwndwrittenbytes :=  CreateWindowEx(0, 'STATIC', 'Geschriebene Bytes: N/A',
          WS_VISIBLE or WS_CHILD, 10, 150, 200, 15, hWnd, IDM_INFO, hInstance,
          nil);

mfg fürs erste
Daniel

[Luckie]

Zitat:

Zitat von Kernel32.DLL

also:

=> AV beim Beenden des Programms: Ich konnte den Fehler lediglich mit deiner kompillierten Version reproduzieren. Bei mir (Delphi 5 Professional) ist der Fehler mit meiner kompillierten Version nicht reprduzierbar.

Dann hab eich wohl etwas andere Compilereinstellungen oder D5 ist gutmütiger.

Zitat:

=> Zeile 648:

Delphi-Quellcode:

Integer(CW_USEDEFAULT), // Luckie: Wert verletzt untere Grenze

Nö. Oder hatte das, was vorher dort stand die unteren Grenzen verletzt?

Das was vorher da stand, hat die untere Grenze verletzt.

Zitat:

=> Warum hast du denn das hier gelöscht:

Delphi-Quellcode:

      hwndwrittenbytes :=  CreateWindowEx(0, 'STATIC', 'Geschriebene Bytes: N/A',
          WS_VISIBLE or WS_CHILD, 10, 150, 200, 15, hWnd, IDM_INFO, hInstance,
          nil);

War ein versehen. Ist wohl beim Aufräumen passiert.

Aber kümmer dich doch mal um die wichtigen Sachen: Die kopierten Dateien sind größer als die originale und immer diese angeblichen fehlerhaften Bytes.