Can you get a strict VI ref without statically linking to the VI?

[Stobber]

I want to use the ACBR nodes to launch and unload a VI, but they need a strict reference and I only know how to create one of those using a Static VI Reference. Statically linking to these VIs causes some build issues on other people's machines, though. Do I have to go oldschool and use the "Run" method with a non-static reference, or is there a way to get a strict reference without statically linking to the VI that I want to launch?

[Darin]

Simply create a constant from the reference terminals of Open VI reference or any of the ACBR or CBR nodes and you get a VI Type Specifier constant.  You can drag a VI on top of the constant to set the type, or choose browse under Select VI Class on the right-click menu.  Either way, the VI you choose is not statically linked, it simply sets the type.

[drjdpowell]

You can also create a constant from a strict reference to the VI, then just delete the reference.

[Stobber]

Completely unintuitive, but it works! Thank you gentlemen.

[Rolf Kalbermatter]

Simply create a constant from the reference terminals of Open VI reference or any of the ACBR or CBR nodes and you get a VI Type Specifier constant.  You can drag a VI on top of the constant to set the type, or choose browse under Select VI Class on the right-click menu.  Either way, the VI you choose is not statically linked, it simply sets the type.

 

But beware. Even if you create a strict typedef of this "Strict VI refnum" control, it will not update its instances if you chance the connector pane of the VI and also change the strict typedef to link to this new connector pane. You have to go into every place where you used this control even if you used the strict typedef, and update it to use the new connector pane. Quite painfull if you try to built a plugin interface.

 

And it's not really unintuitive. It was the only way to open a VI Reference for use with the Call By Reference node, before the static VI refnum was introduced.

[Stobber]

Quite painfull if you try to built a plugin interface.

 

And it's not really unintuitive. It was the only way to open a VI Reference for use with the Call By Reference node, before the static VI refnum was introduced.

 

Lots of things about building plugin interfaces in LabVIEW are quite painful.

 

So it's intuitive only to someone who started using LV before the static VI refnum was introduced...what percentage of total users do y'all constitute? As a LV 7.1+ power user, I had to post on LAVA to figure it out. I'd say that presents a case for reconsidering the UX on this feature.

[drjdpowell]

You have to go into every place where you used this control even if you used the strict typedef, and update it to use the new connector pane. Quite painfull if you try to built a plugin interface.

I just tried making a strict reference constant a type def, and I could easily update it in multiple locations from the type def.

[Darin]

Of course when you create the constant it is only the VI reference which is strictly typed.  If it is subject to change, it should be encapsulated like anything else, and as drjdpowell just mentioned, the Type Def is a natural choice.  

 

Completely unintuitive, but it works!

 

Somedays I'd say that makes a pretty good slogan for LV....

[Rolf Kalbermatter]

I just tried making a strict reference constant a type def, and I could easily update it in multiple locations from the type def.

 

Well, maybe we are not talking about the same. I had a hell of a time (admittedly in earlier versions than 2014) when developing a plugin interface using CBR. Every time I updated the connector pane of the plugin VI in any way (just fixing a typo in an enum is enough) I had to go into every location where I had loaded the plugin through Open VI Reference and relink the strict VI refnum with the new connector pane or the CBR would return an error because the actual connector pane was not matching the expected one. Making the Strict VI Reference a strict typedef didn't seem to help.

 

Since some time I use LVOOP with the factory pattern to implement plugins so have not tried the CBR approach anymore. Some posts on other fora made me believe that it is still a problem even in recent LabVIEW versions.

 

Plugin devolopment is generally a pain in just about any programming environment I have tried. You either have problems at edit time to make sure the interface stays fully consistent or at runtime when trying to load the plugins and often both. The next problem is to make sure the plugins are where your software expects them to be, independent of running in debug mode in your IDE or in the final application. Nothing that specifically more difficult in LabVIEW.