Creating a class from a template class doesn't work correctly if the template class inherits from another class

[styrum]

Here is an issue I ran into with creating classes off class templates in OpenGDS.

I want a template class (which I put into <LabVIEW 20XX>\resource\Framework\Providers\Open_GDS\ClassProviders\Provider_EndevoGOOP400\Templates) to inherit from another "base" class located in, say, my library in vi.lib.

If the template class makes calls to its parent methods (which it has all the rights to do as its ancestor), when I create a class of that template I obviously expect the newly created class to inherit from the same "base" class and to make the same calls to the "base" class methods as the template class does. However what actually happens is that in the generated class's methods I get the same code broken which works fine in the template itself. LabVIEW can't find the subVIs for calls of methods of the "base" class (puts question marks in place of subvi icons, "subVI is not found"). Moreover, it tries to screw up (overwrite) the template class itself with the broken code when trying to close the project or exit! Good thing it at least asks a permission but why does it modify the template code in the first place just because I created another class of off it?!

Here, to make reproducing this problem fast for you I attach some code:

1.Place the "Stans Stuff" folder from Stans Stuff.zip into vi.lib. It contains a library with the "base" class

2. Place the contents of Stans Class 1_class.zip into <LabVIEW 20XX>\resource\Framework\Providers\Open_GDS\ClassProviders\Provider_EndevoGOOP400\Templates. It is my template class which inherits from the "base". If you open it you will see "Read Att1 From Base.vi" method which just calls the ReadAttribute1.vi from the "base" class. Open that method to see that it looks OK and is not broken. Close the template class.

3. Open a new project. Create a New GOOP Class from the Stans Class 1 template class.

4. Open Read Att1 From Base.vi in the newly created class. You will see the question mark instead of the ReadAttribute1.vi icon

The context help says: "ReadAttribute1.vi" was not found. The expected path: C:\Program Files (X86)\National Instruments\LabVIEW 2016\resource\Framework\Providers\Open_GDS\ClassProviders\Provider_EndevoGOOP400\Templates\Stans Class 1_class\Stans Class 1.lvclass.

I.e. Labview now thinks it is the method of the template class itself for some reason, not the method of the "base" class!

The only workaround I found is to not inherit but rather include the "base" class as a data member into the template class. But that's obviously lame as it requires more plumbing code (unbundling a separate wire for the "base") every time I need to call the base class methods from within template class (and classes created off it, of course) methods instead of simply putting the "base" class methods on the same wires of the template class (and its offsprings) itself (themselves).

[MikaelH]

Hi Stanislav,

I've made a small change in the GOOP4 CreateClass VI (see attachment).
Replace the existing VI with this one in this folder:
C:\Program Files (x86)\National Instruments\LabVIEW 2016\resource\Framework\Providers\Open_GDS\ClassProviders\Provider_EndevoGOOP400\ClassWriterGOOP400_class

And let me know if this solves the issue.

[styrum]

Looks like working correctly now as far as creating the new class off the template goes! But LabVIEW still prompts for saving template class  files, i.e. your script still modifies them for some reason when obviously it shouldn't do anything to them.

Also you left a couple of break points in that VI, so make sure you remove them before updating the distributions with it. But first please fix whatever causes the modifications to the template class files during the process of creating a new class off of it.

Update 1: Funny: it kept doing it (asking to save some VIs in the template class on exiting LabVIEW after creating a class off of a template) but then stopped. That's good but something may still not be kosher. Please check.

Update 2: Yes, LabVIEW still insists that the template class has changes that need to be saved, including the .lvclass file of the template itself:

"Some attribute of the library was changed, such as the library version, default menu or icon."

"This class changed which other class it inherits from. The class' version number was automatically incremented."

"Attributes of one or more VIs owned by this library changed. This library has been modified to reflect those changes."

[styrum]

Maybe this should be a separate topic, but why does your "Modify this class inheritance" dialog box see (lists in the drop down box) only the classes explicitly present in the same project? It doesn't even see the parents of those classes.

[MikaelH]

Yes, why do I modify the class we're cloning/copying?!?!?
I try to remember this myself, but I do it in several places (e.g. Create class, Clone Class).
If the class I'm cloning has a parent class (if it's inheriting a class) I remove that links just before I clone the class and then I change it back.
It has to do with the "Save Library as a Copy" function, I think it crashed LV in some cases.
I could try to remove this and see now with LV2016 and later if it still crashes LV.
I see even in 2018 that it does crash LV from time to time, depending on the class you’re trying to clone.

[MikaelH]

I only display the ones you've added in the project, not checking the dependencies.
But sure we could change that.
Add it as a bug in OpenGDS Github.

[styrum]

Can the cloning script(s) work off of a temporary copy of the template class files by using simple file copying of them to a temp folder first (before actually cloning) and then modifying that temporary copy(s) instead of the original if it (modification) is so unavoidable? That modified temp copy then can be saved (if needed) or not but in any case can/must be deleted at the end of the process when it is no longer needed.

[MikaelH]

That could work, as long as the parent class could be found from that new location.
If the Parent class has a relative path from the template class it won't find it....
but If I load the template class in memory first then opens the copied template class (but just renames the lvclass file) if should work.

[styrum]

So will you implement it like this any time soon or should I give up for now on the idea of having template classes which inherit from other classes?

[MikaelH]

I'm working on it right now, I hope having a 2016- version ready next week.
After that I'll focus on the new 2020 version that supports interfaces.