Scripting : Replace a LV Class by a copy of it

[Benoit_Marchand_DAM]

Hi everyone,

I would like to use scripting to create a copy of a class and substitute in the project the original class with the copied one.

I was able to save the copy programmatically using "save a Copy" method.

 

When I added the path to the added the class to the project, I have a conflict (because 2 class have the same name)

Is there a way to substitute a LVClass by another one (that have exactly the same VIs and private properties)  programmatically ? One important remark is that the class is not in the project but in the dependence (this is why I need to make a copy of it)

Thank in advance !

[comrade]

First of all: I haven't tried anything concerning scripting in projetcs here.

But I have an idea which might be a veritable approach to a solution:

How about renaming the offending (to be replaced) class and putting the copied (new) one in the exact same file position bearing the same name as the "old" class, where the project is expecting it according to the dependancy?

Seems like a rather manual process, but, as it's only one class according to your problem, this should be rather easy to accomplish.

[Benoit_Marchand_DAM]

Hi Comrade,

thanks a lot for your fast response.  This seems a good idea but unfortunately it can not be applied in my case because this original class is in Labview depedencies VI.lib (I would therefore avoid copying - deleting - replacing).  Moreover this class will be placed in a Library which complexify this operation. And the last point is that I would like to automatize the process since it should be done automatically for several classes as a prebuild option.

Thank's for your reply and sorry for not providing all details about the requirement.  

[comrade]

Hi Benoit,

possibly this approach might work:

1. find all VIs/CTLs in the project which make use of the class to be replaced (e.g. by using the dependency method on all applicable project elements)
2. open each of those elements, preferrably OUTSIDE the project and replace the "old" class by the copy you made - this might be a bit tricky, as you have to traverse, find and replace all used class elements via scripting, but I think it's possible to do programatically. The Find Dialog of LabVIEW would do this in a jiffy...
3. Save all the elements that you changed the class in.
4. Now TEMPORARILY move or rename the "old" class in vi.lib to keep the project from finding it.
5. open the project and from there open the changed VIs - the project should change and show the asterisk * , but there should not be any conflicts, if everything went as planned and nothing was left out.
6. rename or put back the original class in vi.lib, like it was before you started.

I checked this manually in a simple test, where I created a new project, in there created a new VI and dropped a VI coming from an llb-file into it. Saved all of that and closed the project. Then I copied the llb to some place else and renamed the old one, all with the project closed. Then I opened the newly created VI - the VI in it could naturally not be found, so I replaced it with the one in the new location and saved the VI. Afterwards I opened the project, opened the VI from there, the asterisk in the project window appeared. Saved the project after checking, that the VI still loaded the contained VI from the new copy of the llb. No conflicts, no hassle. Then I named the llb in the old file position back to what it was orginally called. Opened the project and the test-VI yet again - all fine, no conflicts and the VI from the llb was still loaded from the new file hierarchy position.

So this might actually work. Doing this via scripting seems to me straight forward, rather a lot to do though, but I reckon it requires quite some amount of testing and a lot of error handling to be sure nothing in the process goes awry.

#################

As a final proposal: You might want to check whether you can simply change the dependency within the XML-text of the project file itself by replacing the old dependency path with the new. However I do not have any experience in tampering with a project file, so try out at your own risk...The elemtents using the class should of course be changed to use the copy beforehand.

Happy scripting!

Falk from Germany

[Taggart]

Why not the simple answer?  Rename the class...

[comrade]

Oh - this does sound simple.

But would renaming the copied class free him from having to update all callers of the class elements? I think not. So at least all points up to 3 would still have to be performed, I think. And that is where almost all the work needs to be done.

[Benoit_Marchand_DAM]

Thank you very much for your answers,

Sorry for my late answer, it is a side project for me.

At the beginning I tried something similar to comrade proposition (which include replacing all sub VI and functions with the copy of the class). The main issues I faced was for replacement of Class constant.

I investigate the class rename option and I think that I am almost there. I include some code I used to test this solution (LV2017). I still have 2 issues which can certainly be overcomes. 1) the dependencies are only updated when highlight execution is turned on. 2) As soon as I reload the original class , the dependencies to the original class comes back.

I will continue to work on it a little bit and hopefully have those problems solved soon.

Benoît