The ZipFile class, on which the SaveProgress event hangs, in the general case, does not "know" the size of any entry (either compressed or uncompressed) until the entry is saved. Sometimes, maybe most of the time, the entry is
sourced from a filesystem file, in which case it would be easy to determine the length of the file. Sometimes though, the entry comes from a stream, and the length of the stream is not known, and cannot be known, until it is read. So there
is no general, correct way for the ZipFile class to "know", before the Save completes, how many bytes will be read and compressed as part of the Save. Do you see?

If you have the situation where all of the entries in your ZipFile are filesystem files, then YES, you can keep track of that yourself and update a progress bar with that information. But ZipFile does not do that for you.

I can imagine a modification to ZipFile where it provides what you want, if all of the entries are filesystem files. That would be convenient, I imagine. But today it does not do that.