[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.

Attached thumbnail(s)

• 
• 

[Ton Plomp]

DanS, on 29 July 2010 - 01:41 PM, said:

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]

DanS, on 29 July 2010 - 01:41 PM, said:

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]

Shaun Hayward, on 03 September 2010 - 01:12 PM, said:

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]

jgcode, on 03 September 2010 - 01:49 PM, said:

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]

Shaun Hayward, on 03 September 2010 - 01:51 PM, said:

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]

jgcode, on 05 September 2010 - 12:27 AM, said:

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]

Aristos Queue, on 05 September 2010 - 03:26 PM, said:

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.