LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get Malleable VI Path

Solved!
Go to solution
Highlighted

@Darren wrote:

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


I've found my "user-created" malleable VIs don't have this tag (using 2017 SP1).  Is this in a later LabVIEW version, or is there another way to expose this information?  Thank you.

0 Kudos
Message 11 of 21
(268 Views)
Highlighted

Make sure you're reading the tag of the *Instance VI*, and not the original .vim file on disk.

 

To get a reference to the instance VI, you need to get the SubVI reference, then read the "VI Reference" property of the SubVI class. That VI reference should have the _OriginalInstancePath tag.

DNatt, LV R&D
0 Kudos
Message 12 of 21
(266 Views)

So I'm back.  Is there a way to get the path to where a missing VIM should be?  If you open a VI that calls a VIM that is missing the Missing VI Path returns something like:

 

VI With Missing VIM.vi\24edcdda-8bcb-4068-8b29-7aae0b30ca25.vi

 

or is empty.  I'm renaming a bunch of dependencies and I want to scan, and fix dependencies for VIs that might have called the old one.  So I open the VI (possibly without referees).  Look at the path of the missing VI, see if it is one I renamed, and if it is replace it with the path on disk to the name of the new one.  But for this to work I need to get the path to VIMs too.  Attached is a VI that calls a VIM that is missing, and another VI that has some attempts at finding the path to the missing VIM.  If you just open the VI and put context help over it you can see where the path should be, but how do I get that programatically?  Thanks.

0 Kudos
Message 13 of 21
(223 Views)
Highlighted

@Hooovahh wrote:

So I'm back.  Is there a way to get the path to where a missing VIM should be?  If you open a VI that calls a VIM that is missing the Missing VI Path returns something like:

 

VI With Missing VIM.vi\24edcdda-8bcb-4068-8b29-7aae0b30ca25.vi

 

or is empty.  I'm renaming a bunch of dependencies and I want to scan, and fix dependencies for VIs that might have called the old one.  So I open the VI (possibly without referees).  Look at the path of the missing VI, see if it is one I renamed, and if it is replace it with the path on disk to the name of the new one.  But for this to work I need to get the path to VIMs too.  Attached is a VI that calls a VIM that is missing, and another VI that has some attempts at finding the path to the missing VIM.  If you just open the VI and put context help over it you can see where the path should be, but how do I get that programatically?  Thanks.


I did a bunch of digging, but couldn't find it.  If you open "VI With Missing VIM.vi" with a text editor, you can see the missing path;  it appears to be somewhere inside the inlined code, but I was unable to find a way to access it.

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

@Hooovahh wrote:

So I'm back.  Is there a way to get the path to where a missing VIM should be?  If you open a VI that calls a VIM that is missing the Missing VI Path returns something like:

 

VI With Missing VIM.vi\24edcdda-8bcb-4068-8b29-7aae0b30ca25.vi

 

or is empty.  I'm renaming a bunch of dependencies and I want to scan, and fix dependencies for VIs that might have called the old one.  So I open the VI (possibly without referees).  Look at the path of the missing VI, see if it is one I renamed, and if it is replace it with the path on disk to the name of the new one.  But for this to work I need to get the path to VIMs too.  Attached is a VI that calls a VIM that is missing, and another VI that has some attempts at finding the path to the missing VIM.  If you just open the VI and put context help over it you can see where the path should be, but how do I get that programatically?  Thanks.


This code is damn ugly, and not particularly robust, and you'll need to do a bunch of testing on it; but it works (in this case).

"If you weren't supposed to push it, it wouldn't be a button."
Message 15 of 21
(168 Views)
Highlighted

3oziq1.jpg

Seriously thank you.  I did have to make a minor change to support the Open Without Refees.  I didn't really want the browse dialog to come up and have to click Ignore All over and over but using that meant that the Buffer read back didn't have everything it needed.  So I used a Read Text File, reading the whole file on disk instead of saving it as a buffer and that seems to work...again in this case.

0 Kudos
Message 16 of 21
(159 Views)
Highlighted

I actually look like this:

DSCN0261 min.jpg

 I'm the kind of guy who will wear a bright red zoot suit to Disneyland.

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

Just found a bug a short time ago (though it's been there all along).  It wouldn't work of the class was owned by a library (It was just using the class name instead of the qualified class name).  That's fixed now.

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

FYI to everybody on this thread, the 'Missing VI Name' and 'Missing VI Path' properties of the SubVI class should work properly for missing Malleable VIs in LabVIEW 2020, barring unforeseen difficulties.

DNatt, LV R&D
Message 19 of 21
(68 Views)
Highlighted

A much simpler version

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