Scripting: Help with Automated VIM Replacement

[wiebe@CARYA]

---

@_carl wrote:

@wiebe@CARYA: The path returned from a subVI VIM is an internal ".vi" path made by LabVIEW, containing the name of the host VI and a GUID -- so can't be used as described.

---

Ah, yes. Sometimes I still think LabVIEW will do thinks logically...

I'd start with finding all .vims, and looping over only VIs that contain .vims:

But it is rather silly how hard this is.

[wiebe@CARYA]

---

@_carl wrote:

I can come up with a solution to this that works in my scenario, but...  is there a universal mechanism for converting LabVIEW relative paths to the first-found absolute path?

---

If you know what it's relative to...

If it's the project:

If it's the search paths:

[_carl]

---

---

If you know what it's relative to...

---

That's a big "If"!

LabVIEW internally has a way of going down its list of things that relative paths may be relative to -- was curious if this was exposed, rather than re-inventing the wheel.

However, in my case, it now appears that it's irrelevant as my VIMs are holding on to non-existent relative paths.  So instead, I'm hacking together a custom approach that checks the filenames against a list of VIMs I expect my project to be using...and then just replacing those...

[wiebe@CARYA]

---

@_carl wrote:

---

---

If you know what it's relative to...

---

That's a big "If"!

LabVIEW internally has a way of going down its list of things that relative paths may be relative to -- was curious if this was exposed, rather than re-inventing the wheel.

---

That should be the search paths, and the project path.

Those paths should probably be searched recursively.

That 'if' should have been an 'iff' (if and only if). If you don't know relative to what, there's no way to get the absolute path.

I'd expect LV to only store paths relative to a single path, but (again) often LabVIEW's logic simply isn't there.

[_carl]

So...I've found a number of corner cases with @paul_cardinale's solution, thought I might as well capture them here:

- Paths are often no longer valid.  I'm not sure if this is part of LabVIEW's corruption not updating them appropriately, or if this is just a tag that gets generated when a VI is first dropped on the block diagram...but...use caution!  I had to write code that snagged just the filename and checked to see if it matched any VIMs I was expecting.

- Paths are often relative.  This means they can't be used directly -- although it does seem that this path is intended to be relative to the calling VI.

- Paths can be relative to "<vilib>:\" and (I assume) "<userlib>:\".

- "Call Parent Class Method" (and likely some other VIs) were being identified as a vim.  Filtered this out by looking at extension.

- I have a VI that is being detected as a VIM -- even though it is very much a VI.  The path returned form this tag is that of a VIM.  If I drop new instances of this VI into a block diagram, it still has the VIM tag.  My suspicion is that this VI had once been a VIM then I changed it to a VI (and LabVIEW continues to identify it as a VIM...?).  Checking the VI's "IsInstance" tag returns False, so I had to add this into the logic...

[wiebe@CARYA]

The .vim references from the project have a few methods that might do something useful...

I don't have this particular problem though, so I can't test.

In my current project when all .vims break, a save all fixes it. It didn't used to, but after refactoring a bit, what exactly helped isn't clear, a save all is enough.