LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get Malleable VI Path

Solved!
Go to solution

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.

0 Kudos
Message 1 of 21
(4,596 Views)
Solution
Accepted by Hooovahh

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

Message 2 of 21
(4,586 Views)

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

"If you weren't supposed to push it, it wouldn't be a button."
Message 3 of 21
(4,584 Views)

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.

0 Kudos
Message 4 of 21
(4,568 Views)

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

Message 5 of 21
(4,565 Views)

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.

0 Kudos
Message 6 of 21
(4,561 Views)

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.

0 Kudos
Message 7 of 21
(4,545 Views)

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.

0 Kudos
Message 8 of 21
(4,502 Views)

@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?)

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 9 of 21
(4,487 Views)

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.

0 Kudos
Message 10 of 21
(4,483 Views)