Hm, scheinbar lässt sich in der Tat das Problem auf das Entpacken reduzieren. Kommentier ich das aus, läuft es immer durch.

Die Abfrage auf das Busy-Flag fehlte in der Tat. Aber trotzdem scheint es da noch ein Problem zu geben. Fällt jemandem etwas auf?

zusammenfalten · markieren

Delphi-Quellcode:

procedure TfrmImportPSM.UnzipFile(AFilename: String);
var
  zip: TZipMaster19;
begin

  DeleteFileWhenExist(ChangeFileExt(AFilename, '.fdb'));

  zip := TZipMaster19.Create(nil);
  try
    zip.ZipFileName := AFilename;
    zip.ExtrBaseDir := ExtractFilePath(AFilename);
    zip.Extract;
    while zip.Busy do
      application.ProcessMessages;

  finally
    zip.Free;
  end;

end;

Hat die Komponente kein Ereignis dafür? Wenn nicht und die Quellcodes zur Verfügung stehen, könnte es sich lohnen dieses selbst zu implementiere oder die Klasse entsprechend zu erweitern.

Doch, es gibt ein OnStateChanged. Aber auch wenn ich hier auf die Beendigung warte, funktioniert es nicht. Es lässt sich definitiv auf das Entzippen reduzieren.
Hab nun auch die letzte Version von ZipMaster installiert, trotzdem keine Besserung. Dann hab ich mir dem ProcessMonitor mal verfolgt, was da geöffnet und geschlossen wird. So wie ich das sehe, wie die Datei nach dem entpacken ordentlich geschlossen.
Bin langsam mit meinem Latein am Ende, wo ich noch suchen könnte.

Hast Du mal dummymäßig dieselbe Datei in ein anderes Wegschmeißverzeichnis extrahiert und versucht auf dem ursprünglichen Verzeichnis weiterzuarbeiten?

Du meinst sowas in der Art?

zusammenfalten · markieren

Delphi-Quellcode:

procedure TfrmImportPSM.UnzipFile(AFilename: String);
var
  zip: TZipMaster19;
begin

// DeleteFileWhenExist(ChangeFileExt(AFilename, '.fdb'));

  zip := TZipMaster19.Create(nil);
  try
    zip.ZipFileName := AFilename;
// zip.ExtrBaseDir := ExtractFilePath(AFilename);
    zip.ExtrBaseDir := 'C:\temp';
    zip.Extract;
    while zip.Busy do
      application.ProcessMessages;

  finally
    zip.Free;
  end;

end;

So wird die Datei nach c:\temp entpackt, importiert wird jedoch aus dem urprünglichen Pfad (also nicht aus der gerade entpackten Datei).

Interessante Erkenntniss: es stürzt trotzdem ab!
Ich hatte ja vermutet, dass ZipMaster die entpackte Datei noch nicht ordentlich freigegeben hat. Aber das scheints nicht zu sein.
Wenn ich auch noch zip.Extract auskommentiere, dann läuft es wieder problemlos durch. Da scheint irgendwo in den Tiefen von ZipMaster irgendwas gehörig schief zu laufen.

Kommentiere mal die Application.ProcessMessages aus:

markieren

Delphi-Quellcode:

//while zip.Busy do
// application.ProcessMessages;

Zitat von Nersgatt:

Fällt jemandem etwas auf?

  zip := TZipMaster19.Create(nil);

Die Komponente wird dynamisch erzeugt, ohne Owner. Gibt es auch dann einen Fehler, wenn die Komponente auf dem Formular angelegt wird? (Hintergrund bzw. Unterschiede: dann wird beim Einlesen des Formulars auch die Loaded Prozedur aufgerufen, und der Owner ist zugewiesen).

Wieso muss es eigentlich Zipmaster sein? Ich hab mir abgewöhnt, meine Zeit mit dem Analysieren von Fehlern in Komponenten von Drittanbietern zu verplempern.

was würdest Du denn empfehlen? Die Dateien ungepackt auf den Webspace zu laden ist keine Option. Denn das Packen verringert die Größe der Dateien um den Faktor 10 und die Clients haben nicht immer DSL zur Verfügung. Da muss man teilweise mit einem Modem klarkommen (ja, diese alte Crrrrr-Ring-deng-deng-ping-Dinger).

7zip (unten, als "Pascal LZMA SDK" - ist nen direkter Port von 7z auf Delphi/FP)