Hi,

This patch updates TUnZipper so that files can be unzipped to a custom user stream.

To use a custom stream here is an example:

UnZip := TUnZipper.Create;
// both of the following have to be set or
// the builtin method will be used (TFileStream)
UnZip.UseCustomOutputStream := True;
UnZip.OnCustomOutput := @UnZipCustomOutput;

....

procedure (Sender: TObject; var AStream:
            TStream; AItem: TFullZipFileEntry; AClosing: Boolean);
begin
  if AClosing = False then
  begin
    AStream := TMemoryStream.Create;
  end
  else
  begin
    DoSomethingCreativeWith(AStream);
    AStream.Free;
  end;
end;

Also fixed a bug where if a date was not set on a zipfile entry a crash would occur.

Regards,

Andrew

Thanks.

Does it do the same as this proposal:
http://www.hu.freepascal.org/lists/fpc-devel/2009-February/016358.html ?

Is it possible to read zip directories in memory?

Regards
Theo

Andrew Haines wrote

Hi, This patch updates TUnZipper so that files can be unzipped to a custom user stream.

Applied (rev. 13471), thank you very much, this is a useful addition !

Michael.

Do you mind if I say I think this is a very weird event handler?

What is the behaviour? How many times is it called? What does AClosing mean? How do I know I don't have a memory leak?

Why an event handler and not a property? A CustomStream property where non-nil means use this stream, if nil then default old behaviour e.g.

Micha

Well, maybe a bit awkward, but the handler makes sense.

Your Customstream is not possible, because multiple files must be extracted to different streams.

The handler is called 2 times:
- Once to create the stream (aclosing=false)
- Once when the data has been written to the steam. (AClosing=true)

Maybe it had been better to create 2 events:
- OnCreateStream
- OnDestroyStream (optional, if not set the component frees the stream)

What do you think ?

Michael.

This makes a lot more sense that the confusing AClosing usage. Without good documentation the developer would not know what AClosing means. The "self-documenting" events you listed above is much clearer in this regards.

Just my 2c worth... ;-)

Regards,
- Graeme -

Yes, that's more intuitive to me. (Also removes the need for that boolean parameter?)

Would it be allowed to do processing on OnDestroyStream? Maybe OnDoneStream or so would be even better (since that is what it means I guess, the file in the zip stream has been extracted to the specified stream in OnCreateStream?). In Delphi, in an "OnDestroy" you normally don't need to destroy the object the event is about?

Would it be allowed to re-use the same stream?
1) OnCreateStream <- MyStream
2) OnDoneStream <- write MyStream to .... but do not free it
3) OnCreateStream <- same MyStream
etc...?

Micha

I don't see why it would not be allowed, so, yes.

I'll re-implement it as proposed.

Michael.

theo wrote

Thanks. Does it do the same as this proposal: http://www.hu.freepascal.org/lists/fpc-devel/2009-February/016358.html ?

More or less, yes

Is it possible to read zip directories in memory?

It is, as it happens, I implemented that this weekend. The new 'Examine' method now fills the Entries property with the files present in the zip.

Michael.

Micha Nelissen wrote

Do you mind if I say I think this is a very weird event handler?

No, of course not :)

What is the behaviour? How many times is it called? What does AClosing mean? How do I know I don't have a memory leak?

Yes you are right of course. It is confusing.

Why an event handler and not a property? A CustomStream property where non-nil means use this stream, if nil then default old behaviour e.g.

As Michael said a property does not make much sense.

I just looked a the changes Michael made and it is very straight forward now :)

Regards,

Andrew