"Callees Name" in OpenGOOP returns empty string

[OdneOksavik]

Hi everyone,

I'm building a packed library (.lvlibp) that uses OpenG Dictionary. The "Dictionary Create_ogtk.vi" has a sub-sub-vi named "Dictionary Data Store VI Name_ogtk.vi" that will return the string "Dictionary Object Data Store__ogtk.vi" for an "Open vi reference" later.

Dictionary Data Store VI Name_ogtk.vi

When I run this in my library project, it returns this string correctly. However, when I build my lvlibp, and use this in a different project, it will return an empty string. Can someone help me understand why this is happening? Also, what is the purpose of this vi at all? It will always (as far as I can see) return the same string? Maybe if the .vi is renamed, this will help the code not break?

Thank you all in advance!

Update 1: I tried making the vi name a constant, but didn't remove the vi, so it should still be called and be in memory, but now I get an error saying the vi I'm trying to open is not in memory. Why wouldn't this vi be loaded when it's there on the block diagram?

Update 2: I tried removing the checkboxes for the two "Exclude dependent libraries" under Additional Exlusions when building my lvlibp, thinking the vi was removed somehow, but it didn't seem to make a difference.

[tst]

A couple of comments which might help:

The property is deprecated (indicated by the red header and it should also appear in the context help). The OpenG code is quite old, so that maybe shouldn't be a surprise. It's possible someone updated this package in newer OpenG releases, but I'm assuming it wasn't updated. My guess would be that the fact that it's deprecated is the reason this doesn't work for you. PPLs are a much newer feature and when they were written this property was probably no longer supported and no one bothered to make this work.

One guess would be that this property requires the block diagram (although I don't see why), which is stripped when you build a PPL (it might be possible to retain the BD when building the PPL, which would allow you to test this theory, but I'm not sure. You would have to look in the PPL build settings).

Another guess is that the property doesn't know how to return the fully qualified name of the VI, which would change once it's in a PPL. That should be easy enough to test by calling a VI which has this property in a class or a PPL and seeing what it returns.

@OdneOksavik wrote:

Also, what is the purpose of this vi at all? It will always (as far as I can see) return the same string? Maybe if the .vi is renamed, this will help the code not break?

---

That's probably one reason. The other would probably be to ensure the VI is included in builds.

My practical suggestion would be not to use the OpenG dictionary VIs. You can either use variant attributes (keep the variant itself in a DVR to ensure you have a single copy) or a map, if you have LV 2019 or higher. They should provide the same functionality, which wasn't there when the OpenG VIs were written, and should have better performance and type support.

[OdneOksavik]

Thank you for the reply.

I first tried replacing the property with the "Get VI dependencies (Names and paths)" as the help text advises, but still the same issue.

I've used OpenG for so long it has become a part of LabVIEW for me, so I haven't really thought about the fact that it's not getting updated.

I tried disabling the "Remove Front Panel" and "Remove Block Diagram", this resulted in a much larger .lvlibp-file (unsurprising), but still no dice.

My issue is that the vi "Dictionary Object Data Store__ogtk.vi" is not loaded properly into memory, making the property return an empty array of "Callee's" names. Could this be related to the vi in question being set up as "Preallocated clone reentrant execution" ?

As a last effort I gave the VI a "Error out", and wired this to the property, in case it matters if the VI is executed before calling the property (I assume not). Anyway, it does not seem to make a difference.

It seems like my best alternative is your last advice: refactor the code using map.

[tst]

---

@OdneOksavik wrote:

My issue is that the vi "Dictionary Object Data Store__ogtk.vi" is not loaded properly into memory, making the property return an empty array of "Callee's" names.

---

No, that's an assumption. You don't know that. You need more thorough tests if you want to be more certain of what the issue is.

My current guess, based on the following simple test, is that the property simply doesn't know how to deal with VIs in packed libraries:

This shows a VI with three subVIs, but only two are shown in the list. The third one is in a class, which the property doesn't seem to know how to handle. I haven't done an exhaustive test, and haven't checked a VI in a PPL, but I'm assuming it behaves the same. For a VI in a library, the property did actually return its fully qualified name.

You could try debugging this and editing the OpenG code (not a good idea, since it's code which lives in user.lib and others won't have your changes and you could overwrite yours when you upgrade/reinstall) or you could refactor the code. Like I said, there are features in LV which serve the same functionality as the dictionary VIs.

[OdneOksavik]

Correct, it's an assumption. I based it on the fact that when I hard-coded the name of the VI, it gives me the error for "VI not loaded in memory". So I assume the reason Callee and the non-deprecated alternative is not working is simply that the VI is not in memory.

I removed Dictionary and replaced it with Map, and it works good. In some cases it's an even simpler implementation and in some cases (error handling) it's a little more work. Dictionary will give an error if a key is not found, but for Map I have to check this and give the error myself.

So not really a solution to why this failed, but at least a workaround if someone else were to stumble upon this post.

Thank you tst!

[tst]

---

@OdneOksavik wrote:

Correct, it's an assumption. I based it on the fact that when I hard-coded the name of the VI, it gives me the error for "VI not loaded in memory".

---

Still not conclusive. It's possible that the VI really isn't loaded, but checking for the original name doesn't tell you that, because once it's a member in a packed library, that should change its fully qualified name. It's likely that the VI is actually loaded, since there's a static call to it inside the calling VI (which is why using the Callees property worked in the first place).

As for the map, you could probably write a wrapper VI which will give you the same functionality you had until now. You could probably make it a VIM, so you only need one copy of the VI for all data types.