VI paths in a LV 2009 built application

[DanS]

I really like that they figured out a way in LV 2009 to fix the naming conflict problem in a built application. But an unfortunate side effect is that if you want to run a VI within an executable, you must know the full embedded path. Depending on how your sub-VIs are organized, this path can be unpredictable. You can go back to the LV 8.x file layout, but then you are back to the original problem. I figured out a way to have the best of both worlds--it is possible to force a sub-VI to be saved into the "root" of the application in LV 2009.

First off, you need to create a new destination in your build that is the path of the built application.

Then you need to explicitly add the sub-VI to the project, and set its destination to be the new destination you just created.

Now when you build the application, no matter where the sub-VI is located relative to the top-level VI, its path will always be at the "root".

This was really useful when I was building an app as an ActiveX server, and I wanted to call a VI within the app remotely using the VI server.

[Ton Plomp]

This was really useful when I was building an app as an ActiveX server, and I wanted to call a VI within the app remotely using the VI server.

Could you at this info to the LabVIEW wiki?

Ton

[jgcode]

I really like that they figured out a way in LV 2009 to fix the naming conflict problem in a built application. But an unfortunate side effect is that if you want to run a VI within an executable, you must know the full embedded path. Depending on how your sub-VIs are organized, this path can be unpredictable.

I like to use static VI references or relative paths to get around this.

[Shaun Hayward]

or, if you want to use dynamic VIs for memory loading reasons (or some other reason where static links are not so desirable), you can always create a "launcher.vi" in the same folder as the dynamically called VI, that way the path to "dynamic.VI" will always be <launcher.vi's path><stripped 1><appended with dynamic.vi>

[jgcode]

or, if you want to use dynamic VIs for memory loading reasons (or some other reason where static links are not so desirable)

I am under the impression that Static VI Refs do not load the VI into memory but they "link" to the VI (i.e. you do not have to include them in Dynamic VIs in the build spec)?

Or is there some memory hit I am unaware of? (I know Darren says he doesn't trust 'em)

[Shaun Hayward]

I am under the impression that Static VI Refs do not load the VI into memory but they "link" to the VI (i.e. you do not have to include them in Dynamic VIs in the build spec)?

Or is there some memory hit I am unaware of? (I know Darren says he doesn't trust 'em)

I was always under the impression that static refs loaded the linked VI & subVIs just like having a subVI on the block diagram would... This also seems logical to me as with a static VI ref you dont have to open the reference to access VIs properties... still if I'm wrong, that would make static refs even better

maybe someone who knows for a fact can settle this for the both of us

[jgcode]

maybe someone who knows for a fact can settle this for the both of us

You are right, I just checked it out.

I have always like using them as a way to include Dynamic VIs (i.e. in a build) and as an easy way to reference them - esp given the path changes in 9.x build model.

I also like that the top level VI doesn't not break if the Static VI is broken.

i just assumed there would be lazy loading involved if I never did anything with the ref etc...

Anyways now I can keep this in mind

Cheers

[jgcode]

Now I am interested to know - should I be explicitly closing this reference?

Or is it more like a "This VI" reference (which is a constant)?

[Aristos Queue]

Static VI refs...

... do load the referenced VI into memory

... do not need to be closed

... won't do anything if you do call Close on it

[jgcode]

Kudos to you and Shaun for clearing that up for me.

I have another question on references:

If I use, say, an IN that creates a reference e.g.:

If I don't pull the reference out to use it, should I still close it?

(I ask Brian P this at NI Week, but he said without looking at the source code he didn't know).

[Aristos Queue]

If I don't pull the reference out to use it, should I still close it?

Your guess is as good as mine on Project stuff. What does the online help say?

[jgcode]

What does the online help say?

No love from LabVIEW Help on that question.

The LabVIEW shipping example does not close any references, so that didn't give me a hint either way too.

[DanS]

I like to use static VI references or relative paths to get around this.

But my problem involved accessing a VI within an executable that is running as an ActiveX server by a separately running VI (not a different VI within the application). I don't see how either of those methods will work.

[jgcode]

But my problem involved accessing a VI within an executable that is running as an ActiveX server by a separately running VI (not a different VI within the application). I don't see how either of those methods will work.

As you can see from that post I was replying to the first part of your post regarding changes in the 9.x build model.

For your specific use case - you could still use this method by implementing a launcher VI as Shaun mentioned - you only need to know the location of one VI relative to the main VI - but it then it knows all the paths that you need in your build using Static VI refs.

[DanS]

As you can see from that post I was replying to the first part of your post regarding changes in the 9.x build model.

For your specific use case - you could still use this method by implementing a launcher VI as Shaun mentioned - you only need to know the location of one VI relative to the main VI - but it then it knows all the paths that you need in your build using Static VI refs.

I'm curious, what do you think of my particular approach for solving the problem? In my specific case, I have several VI that I intend to export from my application. By forcing the VIs to be placed in the "root" of the application, I can find the VI's directly by name without having to rely on any other lookup mechanism. I was actually trying to highlight a trick with the application builder, i.e. creating a custom Destination that pointed to the Application itself and by explicitly setting the Destination for any VIs that I want to export. Now I can use a general purpose Call Exported Function VI to access the VI.

[jgcode]

I'm curious, what do you think of my particular approach for solving the problem?

I like the idea - well any/all new ideas! (and I have not seen that posted before).

I have not tried it - but my only concern off the top of my head would be: what happens if you wanted to call two namespaced VIs that have the same disk name - and you forced them to compile into the root?

I am guessing that would cause a clash and one would automatically get bumped somewhere else - then how do you find it?

The 9.x can change a lot so I try to avoid messing with it i.e. if you call VIs outside your project, but not a symbolic path i.e. on C and D drive (not that anyone with any experience would do) I am pretty sure another layer gets added.

IMHO I have found use the static ref as a method to point to VIs is much easier, plus I don't have to handle src vs dist path differences in my code.

[Mellroth]

I'm curious, what do you think of my particular approach for solving the problem? In my specific case, I have several VI that I intend to export from my application. By forcing the VIs to be placed in the "root" of the application, I can find the VI's directly by name without having to rely on any other lookup mechanism. I was actually trying to highlight a trick with the application builder, i.e. creating a custom Destination that pointed to the Application itself and by explicitly setting the Destination for any VIs that I want to export. Now I can use a general purpose Call Exported Function VI to access the VI.

I'm not particularly found of using the properties in the application builder to solve something that could be solved in LabVIEW. If everything is handled in LabVIEW I could launch the application on one computer and use another PC as a client, and this gives me complete control during testing/debugging. The application builder trick prevents me from doing this, or requires special handling if we are in an application or in development.

Maybe I'm missing the point, but once connected you can always query the application for a list of exported VIs

• On the server side you can use the Static VI refs to get the qualified names of the VIs to export, and then define these as exported using the "Server:VI Access List Property" to enable remote access.

• The client then only has to connect to the server, and use the "Application:Exported VIs In Memory Property" to get the available server methods regardless of where they are located in the application.

/J

[DanS]

I like the idea - well any/all new ideas! (and I have not seen that posted before).

I have not tried it - but my only concern off the top of my head would be: what happens if you wanted to call two namespaced VIs that have the same disk name - and you forced them to compile into the root?

I am guessing that would cause a clash and one would automatically get bumped somewhere else - then how do you find it?

The 9.x can change a lot so I try to avoid messing with it i.e. if you call VIs outside your project, but not a symbolic path i.e. on C and D drive (not that anyone with any experience would do) I am pretty sure another layer gets added.

IMHO I have found use the static ref as a method to point to VIs is much easier, plus I don't have to handle src vs dist path differences in my code.

The simple answer is, I don't. I explicitly set it up so that the exposed VI were all uniquely named.

The whole exercise was meant to try and get the "best of both worlds" vis-a-vis the internal directory structure within an application built in LV 2009.