[quote=166903:@Frank Foerster]I don’t like using plugins since I want to have the control about what I write and want to understand how it works. Plugins appear like black boxes to me that can easily break.
Tomas Jakobs , can you please closer explain your source code ? I don’t know how to convert this into Xojo.
[quote=166903:@Frank Foerster]I don’t like using plugins since I want to have the control about what I write and want to understand how it works. Plugins appear like black boxes to me that can easily break.
[/quote]
(Respectfully speaking of course) This statement I wanted to point out is as far from the truth as I have experienced. We have experienced 100% readability, documentation, and support from MBS, Bob Keeney, Jeremie Leroy, and Einhugur. We have increased our capabilities and have sped up development sprint cycles since we began using plugins from these professionals .
Interesting way of seeing it. You are already using plugins when you use Xojo. What is the different from Xojo’s Plugins + Xojo’s Libs compared to MBS ?
[quote=166386:@Tomas Jakobs]I do not know if COMPRESS is included in latest Windows versions (in my Win7 Pro it is not).
An alternative (before shelling sth out) could be in using Declare with COM in WIndows.
Each Windowversion since WIndows XP has an built in Zipper. I’ve found these lines for VBS but it should be easy to connect to COM object and modify it for xojo.
Using SourceFolder as Source and ZipFile as Target:
Indeed ZlibCompression of Memoryblock would be a more elegant solution. And there is nothing worse in using additional Plugins. They may save you a lot of time. On the other side I fully understand your concerns.
Ja this article describes pretty well what I’ve meant…
Back in my VB6 times I’ve used Visual Basic DLLs, registred them to WIndows (regsrv32 yourname.dll) and made them accessable from other software, WSH, ASP Webserver scripts. Even between Windows PCs via DCOM. But I used this technique 10 years ago but basically it should still run in todays windows versions.
Check the Xojo documentation for Declares. They are using shared Objects and Functions in USER32 Lib.
Not only that, but from my perspective, a whole lot of what Xojo does for us is a “black box.” We’ve generally had great luck relying on reputable third-party black boxes…
Sorry, I don’t want to harm any business run here in this forum. If people are selling plug-ins here mainly, that’s okay. But I want to manage tasks by using native Xojo only.
you can use shell commands, depending on each platform you compile for
then it’s only a shell command from xojo that will compress your datas
I too dont like plugins because for the 25 years+ I program, often the original program has major updates
and the plugin maker closes his shop for any reason. and you are with something you cannot longer use
and that can be a pain to program another way
so better use the original langage of the tool you’re using if you can.
[quote=167631:@jean-yves pochez]you can use shell commands, depending on each platform you compile for
then it’s only a shell command from xojo that will compress your datas
I too dont like plugins because for the 25 years+ I program, often the original program has major updates
and the plugin maker closes his shop for any reason. and you are with something you cannot longer use
and that can be a pain to program another way
so better use the original langage of the tool you’re using if you can.[/quote]
The issue is Xojo may not be fast enough to have the performances required.
Compression using shell is a valid method on Mac OS X which has a built in Zip command. On Windows, only the unzip function is available, so a third party compression program is mandatory.
There is not very much difference between a plugin and a shell program in terms of independence from the black box. One is more tightly integrated the other. It may be possible to find a free implementation of zip usable from the command line, but distributing it with a program could be a challenge.
I dont know if there are royalties to include a zip/unzip program in a development tool
but xojo should really implement a folderitem.zip and unzip method.
[quote=167654:@jean-yves pochez]I dont know if there are royalties to include a zip/unzip program in a development tool
but xojo should really implement a folderitem.zip and unzip method.[/quote]
You should file a feature request if you want that suggestion to be noticed.
[quote=167631:@jean-yves pochez]you can use shell commands, depending on each platform you compile for
then it’s only a shell command from xojo that will compress your datas
I too dont like plugins because for the 25 years+ I program, often the original program has major updates
and the plugin maker closes his shop for any reason. and you are with something you cannot longer use
and that can be a pain to program another way
so better use the original langage of the tool you’re using if you can.[/quote]
Just be aware that the OS tools can also change over time. There are shell commands that have been replaced by other commands and are no longer available, especially on Windows. One is not necessarily better than the other.
Due to the 2^32 limitation of zip files:
Up to 4 GB maximum zip file size after zipping
No individual file within the zipped file (pre-compression) can be over 4 GB
I think later versions of zip files (like MacOS X) are 2^64 so remove these limitations.
MBS implements 64bit Zip file format, so it may even go over 4 GB…
And MBS Plugin uses 64bit file IO to allow more than 4 GB for zip file.
But please try with test data to verify.