After many blog posts and issues asking to use zip, (something that was already there), Xojo finally add compression methods after a decade.
But they decided to add the feature as part of the FolderItem istead of creating a new Zip Object. What is the problem? they have File Compression but not In memory Compression as a lot of issues asked for
They have had a hidden global class
( _GzipString) that does I’m memory compression compression and decompression of strings that may of us have been using for years…
This lets you create hierarchical folder archives… Yes it could have been done in memory but is is a bit of additional capability (though I have plugins that do that so it does not add any capabilities for me.
This isn’t 110% unheard off in fairness, for example, Windows eventually acquired the ability to unzip files and Explorer treats .zip files as if they were folders, and this functionality is exposed to the .NET CLR, BUT … the API does not support zip file passwords / decryption. For that you have to use a 3rd party library and so you might as well use it for everything. Fortunately at least one is open source / no cost and works well.
That particular example probably reflects a lack of interest in keeping up with every last feature of the zip format and providing just the basic functionality at the end-user level as well as avoiding the possibility of liability exposure due to having a potentially hackable attack surface by even offering a legit way to bypass protection for legit users. I can almost imagine the memo from the company lawyers!
Of course for Xojo it goes way beyond that. They could at least just state publicly they aren’t going to support it at all and refer users to MB/Einghur, et. al.