09-15-2019 05:39 PM
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?
Solved! Go to Solution.
09-16-2019 12:00 AM
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).
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 😉
09-16-2019 08:14 AM
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.
09-16-2019 02:06 PM
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?
09-16-2019 02:21 PM
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.
09-16-2019 02:31 PM
@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.
09-16-2019 02:34 PM
@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.
09-16-2019 02:37 PM
@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.
09-16-2019 02:42 PM
@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.
09-16-2019 02:43 PM
@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.