Excludes Directory?

[hooovahh]

I remember seeing this in a very early Alpha of an OpenG package builder. Lets say I have a set of useful VIs that I made which uses the Variable Manger NI engine and makes some API for it (I don't but for simplicity sake)

 

If I put all my API code in a folder, then make a package out of it using VIPM, it will include all the VIs that I had in my API code, and it will include any sub VIs I used which aren't in the LabVIEW directory or below. This means if I use any code in the Program Files\National Instruments\Shared\Variable Manager folder, VIPM will include them in the package.

 

If I install this package on someones computer they will now have two sets of the Variable Manager code, one in the Shared directory, and one in the user lib, inside the .llb of the package that was installed.

 

This is bad, because now we are unintentionally having multiple (possibly different) versions of NIs code on the same machine, and the package may be using the wrong one.

 

Is there a way VIPM could implement a "Ignore VIs in this directory" feature? For simplicity I would have it include all of the Program Files folder. Thanks.

[TonP]

I think it is a bad idea to use generic VIs outside the LabVIEW x.x folder.

 

Here why:

You have LabVIEW 8.6 and use those VIs in NI\shared.

This means that you cannot use those VIs with LabVIEW 8.2

And it means that installing a package from 8.6 will break existing code in lower versions.

This could only be prevented when you make those VIs read only, which means you have to recompile those VIs on every run.

Besides that it is a good feature request.

 

Ton

[hooovahh]

If you developed a package for 8.6 why would you try to use it in 8.2? I agree that using VIs outside of the LabVIEW directory but in the National Instruments directory is bad, but we didn't put them there, NI did. Some of NIs toolkits and packages installs VIs in folders other than the LabVIEW directory, so then when we use them in reuse code and try to make a package out of it, the package thinks it should include them. But we as the user know that to use this package, you must have that NI toolkit installed already for the reuse code to work.

 

Maybe I repeated myself a little there I just wanted to make sure I was clear on our issue is all.

[Jim Kring]

I agree with Ton that:

 

A) this is a great feature request (and one that is on our radar)

 

there might be a better way to solve the problem, since depending on VIs outside of vi.lib, user.lib, and instr.lib is generally going to cause you problems at some point.

 

One thing that you might consider doing is creating a VI Package of the Variable Manager VIs and have your "API code" depend upon that package.

[crelf]

there might be a better way to solve the problem, since depending on VIs outside of vi.lib, user.lib, and instr.lib is generally going to cause you problems at some point.

Yeah - get NI to start distributing all their addons as VI packages.

 

One thing that you might consider doing is creating a VI Package of the Variable Manager VIs and have your "API code" depend upon that package.

I'm not sure that'll make any difference - then there'll still be more than one instance of the Variable Manager VIs.

[Jim Kring]

Yeah - get NI to start distributing all their addons as VI packages.

 

I'm not sure that'll make any difference - then there'll still be more than one instance of the Variable Manager VIs.

 

I agree with you that there is no ideal solution, except for NI to fix a few things, and that the "exclusion list" in the VI Package Builder would be a good work-around.

 

Looking for a stop-gap solution... one thing that I'll commonly do is create a Call by Reference wrapper API around VIs located outside of user/vi/instr.lib that I need to call. For example, I commonly do this for VIs located in the "resources" folder. How many Variable Manager VIs do you need to call?

[hooovahh]

Looking for a stop-gap solution... one thing that I'll commonly do is create a Call by Reference wrapper API around VIs located outside of user/vi/instr.lib that I need to call. For example, I commonly do this for VIs located in the "resources" folder. How many Variable Manager VIs do you need to call?

I don't know the exact number (I didn't develop it) but I believe it to be around 15-20 VI's and controls.

 

Also the API we have written isn't for the Variable Manager, I just wasn't sure if my boss was okay with me saying what we were developing on a public forum, but it is in the same structure where the VIs we are located in Program Files\National Instruments\[Product name]