Zitat von Sir Rufo:

PS: ITask.Cancel sollte man sich verkneifen

Aber auf die Tasks zu warten scheint auch nicht gewünscht zu sein.
Zumindest bei mir hängt das Testprogramm beim Beenden, wenn noch Tasks abzuarbeiten sind (Infinite timeout).

Wenn ich beim TTask.WaitForAll einen Timeout von einigen Sekunden angebe, dann muss in TaskHasFinished() noch ein if not FShutdown then um den Code, weil es sonst beim Zugriff des TMonitors auf den schon freigebenden FSync knallt.

Oder wie wäre es besser/richtig?

Richtiger wäre es mit folgender Änderung:

zusammenfalten · markieren

Delphi-Quellcode:

function TMainForm.CreateProc( const AID: string ): TProc;
begin
  Result :=
    procedure
    begin
      Log( AID + ' started' );
      try
        Sleep( 1000 );
      finally
        Log( AID + ' finished' );
      end;
    end;
end;

procedure TMainForm.Log( const AMsg: string );
begin
  if csDestroying in ComponentState
  then
    Exit;
  TThread.Synchronize( nil,
    procedure
    begin
      ListBox1.ItemIndex := ListBox1.Items.Add( AMsg );
    end );
end;

Hallo,

ich habe das Zippen mittlerweile auf TThread umgestellt. Die TTask-Variante ist ja Unsinn für dieses Vorhaben. Es läuft auch weitgehend problemlos. Nur mit der Fortschrittanzeige bei einzelnen Threads hab ich noch etwas Schwierigkeiten. Es funktioniert aber, und somit könnte es auch ein Problem mit ZipForge sein.

Im Lauf des Tages werde ich die aktuelle Version mal posten. Soll es als gezippte Datei sein (pas+dfm)?

Zitat von Sir Rufo:

Richtiger wäre es mit folgender Änderung:

Jetzt ist es stimmig.

Zitat von TiGü:

Zitat von Sir Rufo:

Richtiger wäre es mit folgender Änderung:

Jetzt ist es stimmig.

Darum sollte der TE sich ja auch den Source vom Background-Worker anschauen.

Ich verwende auch nicht alles stumpf was ich so finde, bin aber immer neugierig auf den Lösungsweg und die einzelnen Detail-Lösungen.

Zitat von Sir Rufo:

Ich verwende auch nicht alles stumpf was ich so finde, bin aber immer neugierig auf den Lösungsweg und die einzelnen Detail-Lösungen.

Genauso handhabe ich das auch. Jede Zeile Quellcode in allen meinen Sourcen möchte ich auch vollständig verstehen. Da geht gar nichts mit Copy&Paste von irgendwelchen Beispielen, die dann laufen, und ich weiß nicht warum. Das muss auch so sein, denn wenn ich ein Problem habe, muss ich es selber lösen können. Denn, ich hab keinen Cheffe den ich fragen kann.

In Bezug auf den Background-Worker heißt das: Hab noch nicht durchschaut wie das Teil arbeitet, also ignoriere ich es vorerst, weil mir der Lernaufwand in Relation zu den Wünschen (nicht Anforderungen) die ich bzw. meine Kunden haben haben, momentan (noch) nicht gerechtfertigt ist. Als Einzelkämpfer muss ich mir meine Zeit sehr genau einteilen. Darum bitte nicht falsch verstehen.

Anbei nun das kleine Projekt. Wer noch Fehler findet, bitte mitteilen. Ansonsten muss man ja für den Fall, dass man ZipForge nicht hat, nur den kleinen Teil des Zippers austauschen, und hat eine kleine Backup-Lösung für die schnelle Sicherung zwischendurch. Bei mir ist es gerade mit ~23 GB an ZIP-Dateien durch gelaufen. Am Anfang läuft es ziemlich flott los, aber wenn der HDD-Cache mal voll ist, wird es natürlich langsamer.

Zitat von mm1256:

Die TTask-Variante ist ja Unsinn für dieses Vorhaben.

Warum das? Ich hab das "auch" über ein TTask gemacht... Ich durchsuche die Festplatte und erzeuge irgend etwas zwischen 1000 und 1500 TTask's...

Die schlummern dann alle erstmal in der Thread.Queue und es werden immer so viele Worker gestartet wie der Rechner Kerne und CPU Auslastung hat... Eben nach der Automatik der Library...

Bingo...