How do I inherit from a class defined under "vi.lib"?

[DavidFCannock]

I've been developing a series of reusable LabVIEW packages for my company. Up until now, my strategy for reusing packages has been to convert them into packed libraries when complete and add those packed libraries (and any others it depends on) into a 'lib' folder within the root directory of other projects that would need to depend upon them.

Today I found out that I could use VIPM to distribute my packages a lot easier. I've managed to build and install VI packages for of my bottom-layer packages (the ones that don't depend on anything else). All the files related to those packages are now installed under my 'vi.lib' folder on my local machine. I'm now trying to update a project on the next bottom layer, which depends on two bottom-layer projects.

Call this project "Project C" and say it depends on Project A and Project B. Originally, I would have had something like the following:

.

└── lib
    └── ProjectA.lvlibp
    ├── ProjectB.lvlibp

├── src
    └── ...

In Project C, I define a class that inherits from a class within Project A. That works absolutely fine because when I go to Project C's class properties and its Inheritance tab, I can see and select the classes contained with the locally-kept lvlibp files.

Now that I've installed Project A and Project B as packages under "vi lib", it doesn't make sense to keep packed library versions of them under a local 'lib' folder. However, after having gotten rid of them, my class in Project C complains about inheriting from a missing class, and I don't see an option to point it towards the same class kept under "<<LabView>>/vi.lib/My Company/Project A".

How can I create VI packages that contain classes that extend upon classes defined in other VI packages that have been installed on my local machine? How can I refer to controls installed with packages in general, in addition to just VIs?

[tyk007]

---

@DavidFCannock wrote:

I've been developing a series of reusable LabVIEW packages for my company. Up until now, my strategy for reusing packages has been to convert them into packed libraries when complete and add those packed libraries (and any others it depends on) into a 'lib' folder within the root directory of other projects that would need to depend upon them.

Today I found out that I could use VIPM to distribute my packages a lot easier. I've managed to build and install VI packages for of my bottom-layer packages (the ones that don't depend on anything else). All the files related to those packages are now installed under my 'vi.lib' folder on my local machine. I'm now trying to update a project on the next bottom layer, which depends on two bottom-layer projects.

Call this project "Project C" and say it depends on Project A and Project B. Originally, I would have had something like the following:

.

└── lib
    └── ProjectA.lvlibp
    ├── ProjectB.lvlibp

├── src
    └── ...

In Project C, I define a class that inherits from a class within Project A. That works absolutely fine because when I go to Project C's class properties and its Inheritance tab, I can see and select the classes contained with the locally-kept lvlibp files.

Now that I've installed Project A and Project B as packages under "vi lib", it doesn't make sense to keep packed library versions of them under a local 'lib' folder. However, after having gotten rid of them, my class in Project C complains about inheriting from a missing class, and I don't see an option to point it towards the same class kept under "<<LabView>>/vi.lib/My Company/Project A".

How can I create VI packages that contain classes that extend upon classes defined in other VI packages that have been installed on my local machine? How can I refer to controls installed with packages in general, in addition to just VIs?

---

The problem you have is that once a class is built into a PPL that class is namespaced. In effect, it is a completely different class than the original source copy. Since VIPM packages only zip the source and then deploy to the approriate folder, the class name remains intact and any other VIs you have would be able to correctly re-link to this version in vi.lib (as long as they don't find another copy in the order of your search paths).

To my knowledge, LabVIEW doesn't automatically re-link if the class is not identical to the missing version.

The only option I am aware of is to replace all the class controls etc. with ones from vi.lib. There are ways to script this, and quick-drop could also help in this regard to help speed the process up.

[DavidFCannock]

---

tyk007 wrote

The problem you have is that once a class is built into a PPL that class is namespaced. In effect, it is a completely different class than the original source copy. Since VIPM packages only zip the source and then deploy to the approriate folder, the class name remains intact and any other VIs you have would be able to correctly re-link to this version in vi.lib (as long as they don't find another copy in the order of your search paths).

To my knowledge, LabVIEW doesn't automatically re-link if the class is not identical to the missing version.

The only option I am aware of is to replace all the class controls etc. with ones from vi.lib. There are ways to script this, and quick-drop could also help in this regard to help speed the process up.

---

I believe you're right that LabVIEW treats classes within PPL's differently to those outside of them. The thing I'm confused about is how do I go about easily basing the work I'm doing within 'Project C' off of code within 'Project A', if say I want to have a class in Project C inherit from one within Project A? Your suggestion is to directly relink to the code installed within "vi.lib", but is that a robust way of going about it? If another person wanted to install and use code I write within Project C after I've built and distributed it as a VIPM package, would it be guaranteed to work for them so long as they've installed the dependent VIPM packages as well (Project A & B)? I guess it might if I link everything up using symbolic paths ("<vilib>/My Company/Project A/ParentClass.lvclass"), but I'm not sure how to do that exactly.

Whereas that approach might work for replacing all the class controls, I don't see how it solves the inheritance problem. To make a class inherit from another, the parent class needs to be kept within the project. In a real project I have a 'Command' class (based on the GoF Command Pattern) which I distribute in its own VIPM package and have installed under my local machine's "vi.lib" folder. I have another class "CriticalShutdownStrategy" within a 'higher-layer' project that I want to extend the Command class. However, right now the inheritance screen within that higher-layer project looks like this:

It won't let me refer to any classes outside of the project. I guess I need some way to bring the Command class stored under "vi.lib" into my project. The only way I can think to do that is to add the subdirectory under "vi.lib" containing the Command class to my project, but that seems like a really bad and inflexible way of doing things.

I think I can make my intentions clearer by explaining what I'd do if I were working in another programming language like Java. In Java, I would create a new project called "Command", a package "org.mycompany.command" and an interface called "Command", defined as:

public interface Command {
    void execute();
}

Using a build management system like Maven or Gradle, I'd compile the code, assign it a version number, convert it into a JAR file and then publish that JAR to a Maven repository - VIPM seems to be very much like the Maven of LabVIEW in this regard.

In a new Java project where I'd like to have CriticalShutdownStrategy, I would add "org.mycompany:command:X.Y.Z" as a dependency within "pom.xml" (Maven) or "build.gradle" (Gradle). This would make sure that version X.Y.Z of the Command package was downloaded and stored on the project's classpath. This would allow me to produce the class CriticalShutdownStrategy as follows:

import org.mycompany.command.Command;

public class CriticalShutdownStrategy implements Command {
    @Override
    public void execute() {
         // Do something!
    }
}

So essentially the question I have is: how do I do something like that in LabVIEW?

[ESST]

I may have misunderstood the problem, but you might try adding the class from vi.lib to project C, via right click menu. That should make it available as a parent. Once you have selected it at a parent, you should be able to remove it from the project. 

[tst]

---

@DavidFCannock wrote:

It won't let me refer to any classes outside of the project. I guess I need some way to bring the Command class stored under "vi.lib" into my project. The only way I can think to do that is to add the subdirectory under "vi.lib" containing the Command class to my project, but that seems like a really bad and inflexible way of doing things.

---

You don't need the folder, just the class file. You can right click and add, as mentioned, or simply drag it in. This is similar to the import line in your Java code, except you only need it temporarily. And yes, it's a relatively painful way of specifying a source class for inheritance. I guess NI never went back to make this process easier. There should be some ideas in the idea exchange for simplifying this process (such as doing this graphically by dragging in a tree).

Beyond that, you should be careful with how you use packed libraries as there are various gotchas on how they use their dependencies, etc. I would suggest reading up on that. The large apps group over on the communities section is a good resource.