GDS(Goop Development Suite)

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

Awesome! Thank you very much, Mikael!

 
0 Kudos
Message 11 of 19
(2,925 Views)

While you are at it, do you think it is possible to create a secondary project provider for a type "VI" ({D60740D6-F254-4BBC-5675-8858F35B810E}) which would allow to copy/move a method from one class to another by drag and drop (currently LabVIEW does not allow that)? I.e. after copying a method VI from one class to another the script would:

 

1. Change the control and indicator connected respectively to the top left and top right terminals of the connector pane (class/reference in and class/reference out) to the target class type

2. Modify the target .lvclass file accordingly to include the new method as a member of the target class (and, of course,  remove it from the source class .lvclass file if it is a move rather than a copy). Maybe instead of modifying the text in/of the .lvclass files directly, you can somehow tell LabVIEW to do it (accept a new method into the new class and remove it from the source class if needed).

3. Replace calls of "..._New.vi" and "..._GetAttributes.vi" with the respective VIs from the target if needed/present.

4. At least try to replace calls of other source class methods with the corresponding methods of the target class. Well if they exist in the target class too, of course. Otherwise, let those calls become "question marks" (subvi not found)

 

I am surprised that nobody has implemented such a... "feature"/"add on"/"utility" yet, many years after introducing LVOOP. Or has somebody?

 
0 Kudos
Message 12 of 19
(2,922 Views)

That sounds like an interesting thing.
I guess if you hold Ctrl down you'll get a copy.
The copy/Clone feature already exists but not like a Dar and drop feature.

The benefit of that is you can clone it to many classes, and it warn if the file already exists.

MikaelH_0-1600147252165.png

 

Message 13 of 19
(2,915 Views)
Solution
Accepted by topic author styrum

There is a new release (1.2.45) that don't disconnect the Parent class before cloning the Class template.

https://opengds.github.io/

 

Take it for a spin and file any errors found here:
https://github.com/opengds/OpenGDS/issues

 

 

 

Message 14 of 19
(2,899 Views)

I will try. But didn't you say that you already saw LabVIEW (up to 2018) crashing when cloning was done like that (without disconnection of the template from parent) and those crashes were the reason for you to perform the disconnection in the first place? What's new in this version then compared to those earlier ones in which you also tried to get away without disconnection?

 
 
0 Kudos
Message 15 of 19
(2,894 Views)

Had the attached error (twice) during installation with VIPM, but in the end VIPM said "No errors"

 

 
0 Kudos
Message 16 of 19
(2,890 Views)

Installation also removed all my templates from C:\Program Files (x86)\National Instruments\LabVIEW 2016\resource\Framework\Providers\Open_GDS\ClassProviders\Provider_EndevoGOOP400\Templates. I have them backed up, of course, but maybe that complete deletion of the contents of that folder shouldn't be done on an update of the OpenGDS itself if you encourage users to store their templates in that folder.

 
0 Kudos
Message 17 of 19
(2,888 Views)

Great job, Mikael! Looks like it works now (well, I had only a couple of tries) without broken VIs in the clone, crashing, or asking to save modified template files after cloning.

 
0 Kudos
Message 18 of 19
(2,884 Views)

I'm lazy, I don't use VIPM when installing it, I just the the Installer_..vi that was much faster before, but I've not tested it lately.

 

0 Kudos
Message 19 of 19
(2,843 Views)