Dynamic Call to VIT that is a member of a LabVIEW Library (LVLIB)

[FTI_Newton]

Application is too complicated to post, so I will describe this in basic terms ..

Consider these VIs as members of an lvlib.

   Template.VIT

   Template Launcher.vi

   func1.vi

'Template.VIT' and 'Template Launcher.vi' are public members of the lvlib.

'func1' is a private member of the lvlib.

'func1.vi' is a subVI on the block diagram of 'Template.VIT '

'Template Launcher.vi' calls 'Template.VIT' dynamically. It gets a path to the VIT, uses that to Open a reference, then runs it with the 'Run VI' method.

Whenever you launch a VIT this way, it creates a new named instance (because it is a template) by appending a number to the VIT name. In this instance, let's call it 'Template 2.VIT'.

Here is the Problem: 'Template 2.VIT' is not executable because it does not have access to the private member of the llvlib, so it cannot call 'func1.vi' from the block diagram. It seems that the instance 'Template 2.VIT' is not a member of the lvlib. Block Diagram error reads...

"SubVI is private and cannot be accessed from this VI."

My question: Is there any way to make the new instance a member of the lv library?

I don't need a workaround, I need to know if this is possible. Perhaps a particualr switch when Open VI Reference is called, or a particualr property that can be changed?

Message Edited by ADAC on 01-16-2007 11:14 AM

[Justin D]

Hi ADAC,

The short answer is no, you cannot do this.  If you set the "Open VI Reference" option to 2, you can open the template itself and this will not have this problem.  But if you need to create new instances of the template this will not work for you.  You may be able to "work around" this (even though work around is a dirty word).  It might be possible to programatically make a copy of this VI on disk and then programatically edit the lvlib file such that your new file is a member of the library.  I haven't tried this myself so I'm not positive this would work but it might.

I hope this helps,
Justin D
Applications Engineer
National Instruments

[FTI_Newton]

Thank you for your reply.

I have a couple workarounds (dirty word!) in mind already, but they really go around my whole programming structure - eck. That's life!