JEDI JCL Compression OnProgress wie verwenden

[Glados]

Zitat:

Wenn Du weißt, in welcher Reihenfolge die Dateien komprimiert werden und Du die Größe der einzelnen Dateien weißt, dann kannst Du jeweils ausrechnen, welche Datei gerade "In Mache ist".

Beides weiß ich.

Ich verstehe langsam nichts mehr.
Ein Testverzeichnis enthält 1800 Dateien. Alle 1800 werden komprimiert aber nur rund 600-700 (manchmal so manchmal so) werden vom obigen Code sowie von meinem erfasst.
In meiner Test-logdatei sind zu gefühlt 99% nur Dateien bis 50KB. Eine einzige Datei von 20MB wurde erfasst, der Rest > 50KB etwa nicht.

So wie es aussieht ist das JCLCompression OnProgress-Event einfach schlecht umgesetzt.

[nahpets]

Protokolliere doch in dem Ereignis einfach mal nur Value und schaue, wie sich der Wert verändert.

Eventuell wird er ja nicht dateiabhängig aufgerufen, sondern mengenabhängig oder alle x% der Gesamtmenge oder alle y Byte. Dann muss das Ereignis nicht bei jeder Datei aufgerufen werden.

[EDIT]
Wenn man in die Sourcen schaut, kann man erkennen / erahnen, dass der Aufruf dieses Ereignisses von der zur Komprimierung genutzten packervariante abhängig ist. Die Häufigkeit des Aufrufes könnte also bei ZIP-Dateien vollkommen anders sein, als bei 7z ...

[Glados]

Zitat:

Protokolliere doch in dem Ereignis einfach mal nur Value und schaue, wie sich der Wert verändert.

Alles schon xfach durch

Value geht so lange hoch bis es MaxValue erreicht und dann ist der Vorgang beendet.

[nahpets]

Das ist klar, aber ist Value immer 100 kb (oder sowas) größer oder irgendwie einfach nur "unstrukturiert" anders, aber auf jeden Fall höher?

Wenn das Ereignis nicht bei jeder Datei aufgerufen wird, kannst Du damit nicht protokollieren, wann eine Datei fertig gepackt wurde.

Ausgehend von den Quelltexten, dürfte das, was Du vorhast, mit dem Werkzeug nicht gehen, zumindest kann ich kein passendes Ereignis, Attribut ... finden.

[Glados]

Doch das Event wird bei jeder Datei aufgerufen.

Das ganze Event scheint irgendwie kaputt zu sein denn ShowMessage((Sender as TJclCompressionArchive).CurrentItemIndex.ToString); gibt auch immer 0 zurück.
Grundlage für das Event ist übrigens TNotifyEvent.

Ich würde die .Compress;-Routine ja selber gerne einbauen statt die fertige von JCLCompression.pas zu nutzen aber ich kann sie einfach in der Datei nicht finden.

Ich habe gerade eine erstaunliche Entdeckung gemacht. Mein alter Code funktioniert komischerweise und sämtliche Dateien werden erfasst. Aber nur wenn ich die ZIP-Methoden verwende statt 7z.
Meine aktuelle Berechnung im Event ist

Delphi-Quellcode:

if ((Sender as TJclCompressionArchive).ItemCount > _globals.CurrentFileIndex) then
 begin
  _globals.FileSizeTmp := (Sender as TJclCompressionArchive).Items[_globals.CurrentFileIndex].FileSize;
  Inc(_globals.BytesCopied, Value - _globals.ValueOld);

 if ((_globals.BytesCopied - _globals.BytesCopiedTmp) >= _globals.FileSizeTmp) then
  Inc(_globals.CurrentFileIndex);

 _globals.ValueOld := Value;
end;

Funktioniert bei TJclZipCompressArchive wunderbar, bei TJcl7zCompressArchive nicht.

[nahpets]

Wie ich bereits weiter oben vermutet hatte:

Der Aufruf der Routine ist nicht dateiabhängig, sondern von der Variante des genutzten Packers.

Wenn ZIP die Routine pro Datei aufruft, heißt das noch lange nicht, dass ein anderer Packer sich aus so verhalten muss.

[Glados]

Ob das pro Datei einmal oder mehrmals aufgerufen wird weiß ich nicht.
Aber egal wie oft, die Berechnung müsste doch eigentlich jedes Szenario erfassen?