Public Polymorphic and Private Instance VIs in Library

[jdeguire]

Hi all!

Using LabVIEW 8.6.1 (32-bit) on Vista 64-bit.  I wanted to make a library that contains polymorphic VIs along with their instance VIs.  The polymorphic VIs would be declared public and the instance VIs they call would be declared private so that the user would deal only with the polymorphic VIs.  The problem is that LabVIEW gives a "cannot reference VI because of scope" (or something like that) error when I try to use one of the polymorphic VIs.  This goes away if I make both the instance and polymorphic VIs public.  I tried making the polymorphic VIs private and the instance VIs public just to see what would happen.  That didn't work, so LabVIEW must be taking into account the scope of both and requiring that both be public.  Since I'm calling only the public polymorphic VI, and the polymorphic VI (which is a part of the library) is the one calling the private instance VI, then it seems that there really shouldn't be a problem.  I imagine this has to do with how polymorphic VIs work (do they simply substitute the right VI upon compilation?), but it would be nice if it worked out more intuitively.  Though maybe I'm weird in what I think is intuitive...

For now, I just put the now-public instance VIs in a Virtual Folder and am telling people that they shouldn't have to mess with them, and it works, but it isn't exactly ideal.

Thanks,

Jesse

[Ben]

---

The J wrote:

Hi all!

...  I imagine this has to do with how polymorphic VIs work (do they simply substitute the right VI upon compilation?),...

Thanks,

Jesse

---

You got it!

LVOOP does the Dynamic Dispatching you desire.

Ben

[tst]

When using polymorphic VIs, you shouldn't really think of them as being different from any other VI. You call the actual VI and the polymorphic VI is only used to collect a bunch of VIs together so that you can choose between them. The choice is always made at edit-time. That's why the VIs need to be public.

As you suggested, "hiding" the VIs in a folder is probably the best option.

[tst]

Also, you might be able to hack around this by opening the library XML file and removing the reference to the VIs, but I'm fairly sure you will get a conflict which will break the code (VI thinks it's owned by the library but the library thinks it doesn't own it). Even if you don't, it's a hack, so I wouldn't recommend it.

[jdeguire]

---

tst wrote:

When using polymorphic VIs, you shouldn't really think of them as being different from any other VI. You call the actual VI and the polymorphic VI is only used to collect a bunch of VIs together so that you can choose between them. The choice is always made at edit-time. That's why the VIs need to be public.

As you suggested, "hiding" the VIs in a folder is probably the best option.

---

That's a good point and I figured that what you said is what's going on under the hood.  However, I think that by not "thinking of them as being different from any other VI" should mean that they should work in libraries like any other VI.  It is certainly understandable why they do not and don't really hold it against LabVIEW or anything like that, but it would be nice and less confusing to new users if polymorphic VIs pretended to be just like any other, if that makes any sense.

It's actually no biggie, since this library is used for internal testing only and I'm sure we'll be fine just putting the instance VIs in a folder.  It might actually work out better for us in terms of maintainence and needing to edit the library.

Ben:  I didn't think about LVOOP before.  That will certainly be worth looking at sometime for future projects, but I'll try this library as it is now (this is fuelled partially by laziness).

Message Edited by The J on 04-22-2009 12:37 PM