>>>>the dfpug and vfx fll include the original zLib C code - and you have the option to tweak the GUI (which was neccessary, as on oodles of tiny files GUI slowed down processing a LOT).
>>>>
>>>>Changed that, added a property for updating GUI every x files processed.
>>>>Hollered long enough to include that into the release - having the source gives you such options and now you can either change or create a subclassed GUI with values set to your needs ;-)
>>>>
>>>>@Christian: If you decide to use Tores mail: Set it to every 20 files at least if not working ALWAYS with multi MB files - 20 is good for small dbf, still to small for .bat, png and small bmp. The C code will run at satisfying speeds ;-))
>>>>
>>>
>>>Thanks for the tip. Since teh VFPCompression started working again, and no other client had the same issue, I did not change that part. However for next time I would try using vfx.fll to see if I can build a wrapper for that one.
>>>
>>
>>You already have a wrapper in form of the GUI which - at least in the vfx version for certain - is included in source.
>>This GUI in original form got a refresh on each file processed by the fll, updated to nnnn of xxxx files in upper right corner. IIRC it was a simple wrap of the screen update call by a if nnnn/thisform.nNewDivisor_by_TG=0.
>>
>>>With 20 files you mean to iterate batches of 20 files each to add them to the same archive, or to add maximum 20 files to one archive and create multiple zip files?
>>
>>Neither. Just NOT call the status update on each file zipped, but according to human perception values. For me such threshholds are in the 5s - 30s range, as the added time for screen update will be irrelevant and on a 1 minute runtime jumps in status bar of a few % every 5s are not taxing back brain calculation ALWAYS triggered ;-)
>>
>>On longer running process it is only necessary to prove process was alive within last 30-90s and show current status: If your runtime is ~15min you have only 900s to look at the screen, updating on each of the xx.xxx files processed on small files is contraproductive ;-)
>>
>>regards
>>thomas
>
>OK I was not aware that you talked about the status window, in my implementation there is no status necessary.
>
(This is from only memory 16+y back, so check documentation, which is/was extensive with Rainer/Uwe/Venelina)
You might reconsider, as anything already coded and easy to tweak to minimize runtime cost is a benefit as your current problem might have been helped by a GUI / method signature the way to zip in vfx.fll was written:
IIRC they had not only pattern and path, but define a callback function hook. In this hook you receive pertinent info about file last processed with a numerical status flag. So if a certain file errors (duplicate name, filename to long and NTFS still set at 2xx max chars, file locked by) you might either add code for your error handler if zip is done inside your app or have the option to offload to separate process with log if stable file subset afterwards unchanged can be identified.
Unless there is a specific wish or need to run in background/unobserved, anything adding less than 5s total runtime from start to task end to add visual progress and/orr err info is ok in my book.

>By wrapper I mean actually an adapter, so that I could switch implementations of different zip tools with the generic interface that the program code uses.

Had read that correctly and give hefty thumbs up for mind set!

Only problem might be that call options of most other tools might offer less granularity compared to the options vfx/dfPug gives you. I have been critical on some parts of vfx and heavy handed on forcing concepts into it few times back (the granularity to implement code at any subclass level - which some developers consider too much flexibility) arose from my automatic injection of "developer class" vs. "fwk class" into the back then FPW-monolithic fwk after daring Rainer into uttering "nice concept but impossible" after a few beers.
I hated to look forward to make apps error free again after each fwk update, which were frequent early this century and so needled him a few times that the impossible did not even take a week until the next update added the "developer class" subclass levels and he had to write the documentation for it ;-)

The integration level and method interface for zip/unzip calls into the fll was perfect for all my needs. The hook pattern is something they know VERY well and the parameter/granularity selection is/was very good IMO. Calling back into a vfp method xxx.xxx times a few times for every (zip)file action (Open, begin add, end add, error add, archive ok, archive error) will add only a few ms if no action on vfp side is warranted - and I already pointed at the option to tweak possibly time consuming GUI.

Earlier I had opted for !WinRar or !7Zip for use cases with few huge dbf as compression levels were better, but I had no problem with their implementation - never looked at vfpCompression, as back then I had direct line to devs in case of problems which did NOT manifest.

So if license is good with your situation, go for it.

regards
thomas