Question

//Thread
Procedure StartUpdating.UnZip;
begin
form2.ZipForge1.FileName := ItemToExtract;
form2.ZipForge1.OpenArchive;
form2.ZipForge1.BaseDir := XXX;
form2.ZipForge1.ExtractFiles('*.*');
form2.ZipForge1.CloseArchive;
end;

PROCEDURE StartUpdating.Execute;
begin
UnZip; // on ZipForge1Password I get error: EInvalidOperation with message 'Canvas does not allow drawing'. The Form is not frozen while archive is being extracted.
Synchronize(UnZip); //  No EInvalidOperation error on ZipForge1Password, but the Form is frozen while archive is being extracted.
end;

procedure TForm2.ZipForge1Password(Sender: TObject; FileName: string;
  var NewPassword: AnsiString; var SkipFile: Boolean);
var  s:string;
begin

if PassSkip then SkipFile:=true else
    begin
    if InputQuery('Pass',FileName, s) then NewPassword:=ansistring(s) else //I suppose EInvalidOperation error is here
        begin
          PassSkip:=true;
          SkipFile:=true;
          ThreadUpdating.Terminate;
        end;
    end;
end;

How can I unzip without frozen form and without EInvalidOperation error? Thanks!

Answer 1

UnZip; // on ZipForge1Password I get error: EInvalidOperation with message 'Canvas does not allow drawing'. The Form is not frozen while archive is being extracted.

This is because you run thread unsafe code ⁽¹⁾ from within your thread. All thread unsafe code ⁽¹⁾ (like most VCL and WinAPI routines) has to run in the main thread. The UnZip routine references form2, which is a VCL component, so you must ⁽¹⁾ use Synchronize to temporarily transfer execution to the main thread.

Synchronize(UnZip); // No EInvalidOperation error on ZipForge1Password, but the Form is frozen while archive is being extracted.

As explained, with Synchronize you deliberately execute code in the main thread, hence it seems to be frozen during the extraction process.

So now you have a little chicken-and-egg-dilemma. One which could be eliminated by creating the ZipForge component @runtime in your thread. In that case, the only user interaction that remains being synchronized is providing a password. The downside is that Synchronize only takes a parameterless method, so you have to do a little work for implementing the OnPassword event handler. It cóuld look like the following:

type
  TUnZip = class(TThread)
  private
    FFileName: String;
    FPassword: AnsiString;
    FSkipFile: Boolean;
    procedure DoPassword;
    procedure ZipForgePassword(Sender: TObject; FileName: string;
      var NewPassword: AnsiString; var SkipFile: Boolean);
  protected
    procedure Execute; override;
  public
    property PassSkip ...
    property ItemToExtract ...
  end;

{ TUnZip }

procedure TUnZip.DoPassword;
var
  S: String;
begin
  if PassSkip then
    FSkipFile := True
  else if InputQuery('Pass', FFileName, S) then
    FPassword := AnsiString(S)
  else
  begin
    PassSkip := True;
    FSkipFile := True;
    Terminate;
  end;
end;

procedure TUnZip.Execute;
var
  ZipForge: TZipForge;
begin
  ZipForge := TZipForge.Create(...);
  try
    ZipForge.OnPassword := ZipForgePassword;
    ZipForge.FileName := ItemToExtract;
    ZipForge.OpenArchive;
    if not Terminated then  {Assuming OpenArchive triggers the OnPassword event}
    begin
      ZipForge.BaseDir := XXX;
      ZipForge.ExtractFiles('*.*');
      ZipForge.CloseArchive;
    end;
  finally
    ZipForge.Free;
  end;
end;

procedure TUnZip.ZipForgePassword(Sender: TObject; FileName: String;
  var NewPassword: AnsiString; var SkipFile: Boolean);
begin
  FFileName := FileName;
  FPassword := NewPassword;
  FSkipFile := SkipFile;
  Synchronize(DoPassword);
  FileName := FFileName;
  NewPassword := FPassword;
  SkipFile := FSkipFile;
end;

Disclaimer: I am unfamiliar with the ZipForge component so this code can be incomplete. You should implement all designtime generated settings in TUnZip.Execute. I even don’t know if TZipForge has an OnPassword event at all, but I made that up from your code.

Edit:

⁽¹⁾ Not all code of the VCL is thread unsafe, and it is not said that every call from within a secundary thread to a main thread control, component or variable is dangerous, but it is good practice to prevent it. To me, the term thread safety is comfortably cautionary. But the actual reason for this unsafety is that all user interface controls (i.e. all windows GDI objects) can only have affinity to a single thread; the main thread.