Looking for the Cleanest Workaround for a LabVIEW Bug

[paul_a_cardinale]

I'm looking for the cleanest workaround for a LabVIEW bug.
I have a library: "Localization.lvlib".
One of the files owned by that library is "L10N.ini", which contains the localization information.
Another file owned by the library is "INI Path.vi". It looks in the library to find the path to "L10N.ini".

Separately from that, I have some Express VIs whose configuration VIs call localization; which means that (downstream), "INI Path.vi" gets called.
The LabVIEW bug is that when an Express VI's configuration runs the first time (on drop), any attempt to get a reference to a library, gets stuck.
I've tried many things; including opening a library reference from a different application context.

So I have to rewrite "INI Path.vi" such that it doesn't reference "Localization.lvlib".
The simplest approach would be to assume the relative path to "L10N.ini"; but I'm wondering if anyone can come up with something better.

My goal is to minimize the breakability of the project; so if I rearrange things, it still works.

[tst]

I think I would go with the relative path. If you want some insurance, you could probably expand it so that if the relative path doesn't work, you start searching for the file.

If your primary goal is to avoid breaking when moving things around in the file system, then I would consider caching the library reference and then using the cached value. The key, obviously, would be in running it once before you drop the express VI and I expect that can be done, but would require some setup (such as maybe having a class with a VI which is set to run on open, which will maybe run it when the class loads or finding a callback VI or project plugin which can run when a project opens) and I expect would be more brittle than the alternative. I haven't played with it to see if there are any options which work, but I don't think I would call it "clean".

[paul_a_cardinale]

Here's what I ended up doing.

[tst]

I don't know if that's cleaner, since you're still assuming a relative path from your VI to the library in the express VI case, but I suppose it does minimize the chances of problems, since it's only for a single VI.

[paul_a_cardinale]

---

@tst wrote:

I don't know if that's cleaner, since you're still assuming a relative path from your VI to the library in the express VI case, but I suppose it does minimize the chances of problems, since it's only for a single VI.

---

It assumes the relative path to the .lvlib file (which is not likely to change); but it does not assume anything about the location of the .ini file.

[Yamaeda]

Why make it so advanced? KISS. 🙂

[paul_a_cardinale]

---

@Yamaeda wrote:

Why make it so advanced? KISS. 🙂

---

Because I want the .ini file in a different folder than the .VI.  And I might rearrange things later; but I don't want things to break if I do that.