LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to inherit parent code that resides in a different project file

Solved!
Go to solution

I am trying to implement hardware abstraction layer for a project. So I have a project file (i.e. Parent.lvproj) that stores all the parent classes (DMM, PSU, etc.) and another project file (i.e. Child.lvproj) that saves all the child classes (NI-DMM, Keysight DMM, etc.). The problem is; I could not find a way to set the inheritance of a child class to a parent class that is in another project file since Parent.lvproj and Child.lvproj are two different project files. I try to do this via Class Properties-> Inheritance-> Change Inheritance and there is no way to set that. Am I doing this wrongly?

0 Kudos
Message 1 of 13
(3,325 Views)
Solution
Accepted by jamesbond0007

You need the Parent.lvclass to be visible in your Child.lvproj, so add it to the project (Child project) then set inheritance. You can after that remove it from the project if you want - it will appear in the "dependencies" section at the bottom of your target (e.g. My Computer).

 

 

Spoiler

Take care that if you have this kind of set up, you probably aren't supposed to change Parent.lvclass in any way from Child.lvproj. They may be in different repositories, etc.

PPLs are a nice way to solve this problem but have their own collection of problems and frustrations. I like them a lot now for most things, but they're completely off-topic for this thread 😉

 


GCentral
Message 2 of 13
(3,277 Views)

Out of curiosity, why the separate projects?  The only valid reason to do this is if you are building the classes into Packed Project Libraries (PPLs).  Then you just need to include the parent's PPL in the child's project and then you can inherit from it.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 3 of 13
(3,219 Views)

The reason I separate the projects is so that the Child class can be further expanded by other engineers in the future; for example adding more test instrument driver supports. I just want the Parent class to be modified minimally, that's why I separate both of them. Is that the right approach?

0 Kudos
Message 4 of 13
(3,199 Views)

Sorry for the noob question here, but what's the implication of changing Parent.lvclass in this setup design? If I compile the Parent project into PPL, then in future, the Parent class will always need to be compiled after editing before being used in the Child project.

0 Kudos
Message 5 of 13
(3,193 Views)

@jamesbond0007 wrote:

Sorry for the noob question here, but what's the implication of changing Parent.lvclass in this setup design? If I compile the Parent project into PPL, then in future, the Parent class will always need to be compiled after editing before being used in the Child project.


Yes, if you change the parent library you will need to rebuild and redistribute the PPL. If you build your child classes into PPLs as well, they would have to be rebuilt. A very good practice is to solidify your API and then not change it. Use the SOLID design principles when defining your classes.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 6 of 13
(3,188 Views)

@jamesbond0007 wrote:

Sorry for the noob question here, but what's the implication of changing Parent.lvclass in this setup design? If I compile the Parent project into PPL, then in future, the Parent class will always need to be compiled after editing before being used in the Child project.


I am left to assume you are referring to going with PPLs here.  Yes, the parent library will need to be recompiled for the children to get the benefit of any updates.  But that should be a minimal issue assuming you have directory structures correctly set up (have the child project use the build output PPL of the parent project).  But the child projects will not be able to "accidentally" make updates to the parent since it will be locked down to a compiled library.  And you will also quickly learn that you really have to use PPLs if you want a good plugin architecture for your executables.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 13
(3,184 Views)

@Mark_Yedinak wrote:
If you build your child classes into PPLs as well, they would have to be rebuilt.

Only if the API changes.  Non-breaking changes, such as changing a constant in a VI, will not require the child to recompile.  At least, that has been my experience.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 13
(3,180 Views)

@crossrulz wrote:

@Mark_Yedinak wrote:
If you build your child classes into PPLs as well, they would have to be rebuilt.

Only if the API changes.  Non-breaking changes, such as changing a constant in a VI, will not require the child to recompile.  At least, that has been my experience.


While generally this is true, we have experienced crashes when we have not rebuilt children PPL libraries even though the change should did not change the API. We are dealing with quite a few PPLs though multi layers deep. I believe we are up to 170 or so PPLs and about 10 layers deep. We automated the build process on Jenkins so it is pretty straightforward to rebuild everything if needed.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 9 of 13
(3,175 Views)

@crossrulz wrote:

@jamesbond0007 wrote:

Sorry for the noob question here, but what's the implication of changing Parent.lvclass in this setup design? If I compile the Parent project into PPL, then in future, the Parent class will always need to be compiled after editing before being used in the Child project.


I am left to assume you are referring to going with PPLs here.  Yes, the parent library will need to be recompiled for the children to get the benefit of any updates.  But that should be a minimal issue assuming you have directory structures correctly set up (have the child project use the build output PPL of the parent project).  But the child projects will not be able to "accidentally" make updates to the parent since it will be locked down to a compiled library.  And you will also quickly learn that you really have to use PPLs if you want a good plugin architecture for your executables.


I would further add that you can protect your parent level source code by keeping it in a separate SCC repository. Only core developers have access to this repository and everyone else MUST use the PPLs.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 10 of 13
(3,170 Views)