Having a class contain a library is completely meaningful and is a more than reasonable request. As is having a class contain a class, a class contain an xcontrol, or, really, any X contain a Y, where X and Y are any of the library types. Unfortunately, you're unlikely to see class contain Y due to some dumb implementation choices that are at this point deeply embedded in the LVOOP implementation. But if it gets enough kudos, it may be worth taking the time to do it.
this idea was first posted when i wanted to use some library VIs in a class an thought it was necessary to have everything in the same "project" in order to use them, but then i found out that this was not the case.
From where i stand now, i can see the point in using libraies in libraries and this is possible.
In my current understanding, i see no need to put libraries inside of classes or classes inside of classes.
Could someone share some concrete situations where this would be advisable?
Kind of weird to ask that question as i am the one who posted the idea!!!
"due to some dumb implementation choices that are at this point deeply embedded in the LVOOP implementation"
This sentence disturbs me to the point of asking if LVOOP is the path i should follow...more details would be appreciated...
On second thought, I am confident that NI as put a lot of effort to make sure that LVOOP is stable and reliable, but i am very curious about "dumb implementation deeply embedded"...can sound kind of scary...
> On second thought, I am confident that NI as put
a lot of
> effort to make sure that LVOOP is stable and reliable, but
> i
am very curious about "dumb implementation deeply
> embedded"...can sound
kind of scary...
Oh, then let me talk you out of using LabVIEW entirely. 🙂 And I can do so without worrying that you'll go use some other software because this is a problem endemic to all good software. When trying to predict the future and the full range of "how do we expect people to use this", sometimes not all the possibilities are taken into acount. This is one of those -- we designed the class architecture in such a way that we couldn't nest other libraries inside of it, forgetting that people would want to do exactly that. It was an oversight. Essentially the project code assumes that if a class refers to another library, that other library must be its parent library. It didn't bother to check further details. Now if we want the class to refer to another library, we'd have to find all the places where that asumption was made and fix them to not just use the first class found but actually check the type of the reference (is this a "owned" reference or an "inherits from" reference?).
The more powerful the system the more common those are. It's why you have new versions because no one gets it all right on the first attempt. Three years after the release, I can say with some pride we did a great job with LVOOP. There have been very few of those sorts of mistakes.
Any idea that has received less than 6 kudos within 6 years after posting will be automatically declined.