OpenG Zip subvis are broken after fresh Installation via VI Package Manager - trial and error

[alexderjuengere]

I am on Windows 11 running LabView 2020 64bit and I want to use the openG zip library, which I downloaded and installed via VIPM

- https://www.vipm.io/package/oglib_lvzip/

The Instalölation process finishes, I close VIPM and restart LabView and I try to read a demo-zip-file.

It looks like the toolkit is written around a central element which is lvzlib.dll

Turns out that most of the vis in the Toolkit don't work, which is due to a wrong path in the call library node.

To original path after VIPM installation is something like "C:\work\...\lvzlib.*" - looks like someones else windows.

So, I open LabView, choose do a mass compile via Tools>Advanced>Mass Compile .... and then set "directory to compile" to "C:\Program Files\National Instruments\LabVIEW 2020\user.lib\_OpenG.lib\lvzip"

Heureka, all the paths in all those subvis have  changed to

C:\Program Files\National Instruments\LabVIEW 2020\user.lib\_OpenG.lib\lvzip\lvzlib.*

But the Toolkits subvis are still broken, however the error description changed

So I manually change the absolute path to the dll like and I get this prompt:

So I check the internet, and I come up with this repository: https://github.com/Open-G/lvzip-library were a lvziplib64.dll can be found

I download this file, rename the original to lvziplib_32.dll and lvziplib64.dll to lvziplib.dll and mass compile again

still a broken white arrow

when I manually change the absolute dll path to 64 version, the vi is no more broken

do I have to do this manually for all calls of the dll node in the toolkit?

Is there something I am missing?

[alexderjuengere]

so, I copy https://github.com/Open-G/lvzip-library extract the folder source\lvzip.llb and change every path in every clf node which is in lvzip.llb manually to an absolute path ending with "C:\....\lvzip64.dll"

there is also a very compact but very well demo hidden inside "ZLIB VI Tree.vi" on how to use the vis in the .llb 

and it works! My first test is to extract a PNG from within a zip as a byte stream - conveniently, the "PNG Data to LV image" works out of the box

Spoiler

this is my main use-case:

general

when you have to read lots of (small) files (~100.000)  from hard drive to LabView, this will take quite some time (Minutes).

But if all files are written into one binary file, it is significantly  faster to just read this one file (Seconds).

special

However, in my case, all those small files are already contained in a single .zip file 

In Python, it is very easy to read the whole zip file to memory, parse the extracted bytes file-by-file and output a "1d array of files" ( like  'remaining elements' when releasing a labview-queue)

In LabView, I have to unzip, create binary file dump, read file dump - that is why I am looking for a more direct approach without a binary dump.

[alexderjuengere · Accepted solution]

I put the 64 bit dll path in a global variabel and use it whenever a CLF Node in lvzip.llb needs it