Get Malleable VI Path

[Hooovahh]

Is there a way to get the path to a VIM, that is placed on the block diagram of a VI?  Attached is a VI with a VIM, and another VI that is attempting to get the path of VIM that is used.  In this case I want C:\Program Files (x86)\National Instruments\...etc.  Is there some secret method or function I'm missing?  Thanks.

[Darren · Accepted solution]

You're almost there. The instance VI has a tag called "_OriginalInstancePath". That should give you what you need.

[paul_cardinale]

---

@Hooovahh wrote:

Is there a way to get the path to a VIM, that is placed on the block diagram of a VI?  Attached is a VI with a VIM, and another VI that is attempting to get the path of VIM that is used.  In this case I want C:\Program Files (x86)\National Instruments\...etc.  Is there some secret method or function I'm missing?  Thanks.

---

The problem is that the .vim is inlined at edit time.  The instance of a .vim on the BD isn't really a subVI (though in some respects it acts like one).  It's really some kind of a frame with the .vim's code jammed inside, and it's icon pasted on top.  There doesn't seem to be any way to get to the properties of the real object.  I almost gave up, then I thought of tags.  After a little snooping, I found it.

[Hooovahh]

Awesome and awesome.  Now the path that is returned has NI short hand for file paths.  Is there a VI somewhere that resolves "<vilib>:\Utility\Stall Data Flow.vim" to the full absolute path?  I can of course write a VI for it but if one exists already I'd rather use that.  I looked over OpenG and hidden gems but didn't see anything.

[Darren]

There is a private method of the LVTarget class (which is a private class) called "Resolve Symbolic Paths" that will turn the symbolic vi.lib path into an absolute path. To get the LVTarget reference, there's a private property of the Application class called "App.LV Target".

Alternatively, you can call this (password-protected) VI that implements everything I just described:

LabVIEW 20xx\resource\Framework\Providers\MessageRescripter\Support\Resolve Symbolic Path.vi

[Hooovahh]

Once again thank you Darren, I'll be adding that VI to my custom palette at some point.  Although I did find that Paul actually answered this in a thread google eventually found.  His method is basically the one you described.

[Kyle97330]

As a side note, depending on the use case of why you need to get the path of a VI from a block diagram, if you run the "Get VI dependencies" method on a VI with the "Keep Express\Malleable?" option set to False, it will output the actual path to the VIM on disk (absolute, not relative to vi.lib) as part of the "dependency paths" output array. 

If you're just trying to get a list of every subVI that a VI calls, using that method is likely easier than parsing through tags and using private hidden functions.  If you need to know about one exact node, it's not an option.

[Hooovahh]

Thanks for the suggestion.  In this case it is dealing with QuickDrop and I really am interested in an item selected by a developer and so Darren's suggestion worked great and hopefully I'll have something to show for it soonish.

[paul_cardinale]

---

@Hooovahh wrote:

Once again thank you Darren, I'll be adding that VI to my custom palette at some point.  Although I did find that Paul actually answered this in a thread google eventually found.  His method is basically the one you described.

---

The VI in that link has a deficiency: It doesn't close the app reference (does that really cause a leak though?)

[Darren]

In your 'Resolve_Symbolic_Path.vi', you need to close the array of Project references in the <lvproj> case, and you need to close the LVTarget reference in the Default case. You don't need to close any other references in this VI.

See my Brainless LabVIEW presentation for more information on which references you need to close vs. which ones LabVIEW handles for you.