OpenG LabVIEW Zip 5.0.0-1 - stuck at the readme

[PA-Paul]

Hi I'm trying to install the OpenG Zip package via VIPM. But when it gets to the LVZIP readme page - the "Yes, install this library" button remains greyed out no matter how many times I scroll to the top or bottom of the dialog... It worked fine on a different computer, but on mine I cannot get past this (and its a tad frustrating!).

I'm on LabVIEW 2021.0.1f2, VIPM 2023.1

I've tried uninstalling the old version, making sure its not installed in any other LabVIEW version, but I get the same results on any version of LabVIEW... Hoping someone can help!

Thanks

Paul

[Rolf Kalbermatter]

Hi Paul

I'm aware of this problem. It has to do with different default fonts in modern Windows machines, which changes the entire text format. The main reason I haven't yet updated the installer was that I was on vacation and there is also a problem to install the package under Linux, which has to do with write permissions to certain file directories. Once I figured that out I will release a new package 5.0.1.

[PA-Paul]

Thanks Rolf, glad to hear its on your radar already.

It's not holding me up in the end as I'm not actively developing anything using the toolkit and fortunately it did work in the place I need it most (the build server!)... but I'll keep my eyes open for the update so I can get it on the dev machines too!

Thanks

Paul

[Rolf Kalbermatter]

5.0.1 and in the meantime 5.0.2 has been since released. One issue, but that is not really new and existed before: Don't disable mass compile after install, it may take some time but it sure fixes stale shared library paths in the VI and I have so far not found a way that makes those paths automatically fixup at package creation, since the path seems to need to be absolute.

The two possible approaches I'm currently considering:

1) use a so called Symbolic Path (/<user.lib>/_OpenG.lib/lvzip/lvzip.*).

Disadvantage:

- only works if installed into default location

2) use Specify Library Name on diagram for the Call Library Node and calculate its path at runtime.

Disadvantage:

- makes the shared library be not a visible component to the VIs, so that the shared library needs to be added explicitly in every application/shared library/assembly/source distribution build in order to be available in such

- extra execution time for the dynamic calculation of the path

Edited April 15 by Rolf Kalbermatter

[ShaunR]

3 hours ago, Rolf Kalbermatter said:

I have so far not found a way that makes those paths automatically fixup at package creation, since the path seems to need to be absolute

This is why it takes me hours to make an ECL build that works and is one of the many reasons only Windows is now supported (can load from same dir). Even then. I have to fight VIPM to get things in the right places.

I refuse to do #2.