Better control over Class / Library membership

[Intaris]

I'm linking to THIS post where for the first time I've heard of someone suffering from the same problem as me.

Basically, the "This VI claims to be part of a library, but the library is being stupid about it" (I may have paraphrased) is solved by selecting the offending VI intruder and selecting "Disconnect from Library".

Problem: If you're programming in LVOOP and are trying to put together a library, this can lead to not only disconnecting from the library but also all of the VIs from their respective classes.  This is a major problem because it breaks a whole load of code and takes literally AGES to fix depending on the extent of LVOOP in the project.

I know Classes are Libraries on the inside but PLEASE give us the ability to view and control membership in a more intuitive way and most importantly independently from each other.

[tst]

I don't understand the problem. A VI can be owned by no more than one library. If the VI thinks it's in the library and the library doesn't know it, you get this conflict. Disconnecting the VI simply tells it it's not part of the library. This should work the same with any kind of library.

What problem do you have with LVOOP and what's your actual suggestion?

[Intaris]

I knew I hadn't explained well, I'll get some pictures up.

Basic problem is when a member of a class is caught up in the "not part of a library" problem you can't remove it from the Library without removing it from it's class also.  It's the same operation -> "Disconnect from Library".  I want the option to manage Library relationships distinct from class relationships.  I want to be able to choose WHICH library I want to remove a VI from.  Currently I cannot do that, it simply removes ALL library relationships.

[SteveChandler]

@Intaris you can't remove it from the Library without removing it from it's class also.

A picture would be good. I am having trouble understanding this. The library that owns the class knows nothing about the class member you want to remove. It only knows about the lvclass file. The lvclass knows that it belongs to the owning library.

Maybe you are saying that the class member vi knows that it belongs to the class AND knows that it belongs to the library that owns the class. That is something that I am unsure of. I cannot imagine why it would need to know about both. If that is true I think it would be extremely difficult to change.

[tst]

> I want the option to manage Library relationships distinct from class relationships.

There is no distinction. Like I said, a VI can't be owned by more than one library and a class IS a library. Once it's a member of a class, it's not a member of any other library and disconnecting it from the library should mean removing it from the class. If you have a class in an .lvlib, then the class is owned by the .lvlib, not the VIs inside the class.

[Intaris]

Yeah, I don't seem to be able to reproduce at the moment, but I'm pretty certain I've run into this problem due to files being accidentally deleted from ourtside the project.  A more intuitive way to solve the Library problems would have saved me loads of time in the past.

[Intaris]

Mods, can you delete this idea, seems like my memory is faulty.  Like that's something new......

[JordanG]

Not reproducible.

[johnsold]

Jordan,

What is not reproducible - the library issue or Shane's memory?

Lynn

[Intaris]

Hmm, what?

I can't remember what we were talking about.....

[Darren]

Not a reproducible issue