The nightmare that is renaming a class and its folder

[GregFreeman]

Alright, this has now happened enough to me that my forehead is starting to hurt from banging it against my desk. I know everyone here gets design exactly right the first time, so maybe this is never an issue for you guys   .

 

We changed our architecture a bit, which meant our "process" classes now needed to be given new names because their responsibilities changed slightly, so the original names didn't make sense. Renaming a class from LabVIEW, no problem, F2 works wonders. But now it's contained on disk in a folder that most likely has the old name. When I rename that folder, stuff often goes haywire. All the methods "can't be found" so I have to open them and save them one by one in their new location (even though they are already there - LabVIEW is just looking for a folder that no longer exists - so I just save over them). Then, God forbid you renamed the class outside the project on disk so the LabVIEW project couldn't update the name of the class it was pointing to. At least LabVIEW is nice enough to let you browse on disk to select the proper class in this case...which has a new name and won't be loaded by LabVIEW anyways because it isn't the class it's looking for. 

 

If I remember right, I think if you rename the class in the project, close the project, change the directory name on disk, then open the project it will search for the class with the new name and you can just point it at the new location. I'm not entirely sure if these are the exact steps. Anyways, does anyone have a typical workflow for renaming a class and where it exists on disk (wtf, a workflow is needed for this?)

Edited November 20, 2013 by for(imstuck)

[todd]

When moving LV entities on disk, I always use the Files tab of the project explorer.

[Darren]

My solution is to never, ever rename classes. I'm serious.

[drjdpowell]

I make a project that holds EVERYTHING that references the classes involved and then rename classes and move things about in the Files tab.  Once the set of things referencing it becomes too big, or I have it in a reuse VI package form, then I’m stuck with Darren’s solution.

 

— James

[LogMAN]

I think the most annoying issue is that you can't actually rename a folder in the files tab of the project (this could be so easy!). I generally go to the files tab, select everything in the current folder, right click -> Move on disk..., create a new folder at the desired destination and press save. As this entirely depends on LabVIEW, there is no relinking done (well there is, but no search dialog). However the old and now empty folder (including the entire filder hierarchy) remains and cannot be removed because LabVIEW keeps locking it (I think it is the search location for the next save/load dialog).

[MartinPeeker]

I'm with Darren on this one. Mostly even down to single vi:s actually.

 

Working with a SCM makes this even worse (might be better if it was integrated, but that is not my luck). I want to rename it in the SCM so that I don't lose the revision history, but that leaves you in the rename-on-disk world of pain for(imstuck) was talking about.

 

I didn't know of the possibility to move files around in the File tab, one of those things I've overlooked, thanks for letting me know about this. How does this work with an inegrated SCM?

[LogMAN]

I'm with Darren on this one. Mostly even down to single vi:s actually.

 

Working with a SCM makes this even worse (might be better if it was integrated, but that is not my luck). I want to rename it in the SCM so that I don't lose the revision history, but that leaves you in the rename-on-disk world of pain for(imstuck) was talking about.

 

I didn't know of the possibility to move files around in the File tab, one of those things I've overlooked, thanks for letting me know about this. How does this work with an inegrated SCM?

 

I haven't looked into it, but the description says I assume it is capable of renaming VIs without loosing the revision history: http://sine.ni.com/nips/cds/view/p/lang/de/nid/211524

Edited November 20, 2013 by LogMAN

[MikeC3]

I've only done this once, but I was able to do a rename of a class and some VIs and keep things consistent with SCM (non-integrated SVN) and LabVIEW.  It does involve repeating yourself and doing a few things that don't feel... right, but the end result seems to be good.  YMMV.

 

First, with LabVIEW closed (and blisfully unaware) make a copy of the files with their new name in your SCM (thus preserving history).  Commit this change, so you now have two copies of the file in your SCM: oldName.lvclass and newName.lvclass.

 

Then, in your working copy (NOT repository) delete the newName.lvclass (and any other files that were copied).  Do not commit this change.

 

Next, open LabVIEW and load the oldName.lvclass into your project.  Everything should be fine, because LabVIEW only sees what is in the working copy.  Now rename (in LabVIEW) oldName.lvclass to newName.lvclass.  You should now see modified versions of newName.lvclass in your working copy.

 

Commit your changes.  This should commit the deletion of the oldName.lvclass (done when LabVIEW renamed it) and the modifications to newName.lvclass (whatever LabVIEW did to make it happy).  You now should have newName.lvclass, with full history, and a happy LabVIEW.

 

Again, YMMV as I've only done this once (in recent memory) because I didn't want to have to redo a day's worth of work over a name.  In normal situations, I stick to Darren's law of never renaming (especially once the file is in SCM).

Edited November 20, 2013 by MikeC3

[unicorn]

Renaming a folder holding a class with Windows Explorer is no problem, because you can afterwards open the class and LabVIEW will find the right VIs relative to the path of the *.lvclass files. Even opening a project file will ask only once where to find the class. Then you could save the class files with "Save all (this Class)" and all class VIs will be saved. But be aware that also all subVIs of the class VIs will be saved as well if they are changed.

 

Renaming a class in a project will become a nightmare if not all callers of that class are loaded in memory.

 

If you want to exchange a class for a different one (e. g. if you have prepared a new revision like in your case) than you could do the following:

1. open your Project

2. add old and new class to the project, if not already done

3. make the new class (temporarily) a child class of the old class

4. replace all class constants of the old class only in the block diagram with constants of the new class. As the new class is a child of the old class all wires, front panel element and class VIs will adopt automatically to the child (new) class. Of course, class VIs are only exchanged if they have not been renamed and if the class in and out is dynamic dispatch.

5. undo the inheritance

6. save everything

 

With this procedure all class VIs are exchanged at once. You have to replace only (normally a few) class constants in the BD but not a large number of class VIs in many caller VIs. To prepare the new revision of a class with a different name use "Save as > Copy -create copy on disk" on the class in the project explorer.

 

You could also apply this method step by step to several projects as you have the old and new class on disk.

[candidus]

Here is something that worked for me (admittedly my class hierarchy was not big):

 

- Create the target folder.

- From your project, save every single VI of the class in the new target folder via Save as -> Rename.

- Rename and save your class in the the target folder.

- Save all affected VIs in the project.

 

If you renamed a folder outside of LV it can help to edit the project file manually.

 

And sorry, not renaming can't be a solution. Code that uses wrong type names or function names is bad, IMO.

The possibilty to refactor code is essential, especially when you have to maintain a project for a long time or work with legacy code.

[PaulL]

I always rename a class from a project, either using Save As... or Move on Disk....  In either case I also specify a new destination folder with the new name.  Methods associated with the class I then move in the project files view.  Yes, as mentioned above, it is necessary to delete the old, now-empty folders outside LabVIEW (from a file explorer application), unfortunately.  (NI changed this for LabVIEW 2010: see "Restore 'Delete from Disk' in project Files view" topic in the Ideas forum for more details.)

 

With TortoiseSVN (i.e., outside LabVIEW) it is possible to specify that one file is the rename of another, so that the new file will keep the old file's history.  I recently joined a new organization that uses Git, and I haven't investigated how to do that with Git yet.

 

I use the LabVIEW IDE's search and replace functionality to update the icon names on the object control and indicator names in the class methods.  This is fairly straightforward, since it is pretty easy to select the VIs in the class for search scope.

 

The process works well enough for me with too much trouble (although I don't always end up being able to link the new file to the old history), but clearly this requires more effort than it should.  (I'm reasonably happy working with TortoiseSVN outside the LabVIEW IDE, but fully capable integration with source code control from the IDE would simplify these steps and reduce errors.)

 

A few years ago someone posted a tool on LAVA designed to facilitate renaming of classes.  I haven't tried it myself.

 

This discussion points out areas where the project (failure to delete folders from disk) and version control integration (inability to rename files effectively--which requires the ability to delete folders) are incomplete in the LabVIEW IDE.  It seems clear to me that a complete solution integrated with the IDE (clarification, a complete integration with external source code providers) would be quite beneficial.  (OK, the fact that some people are seriously suggesting not to rename classes is a pretty big red flag here.)

 

When it comes to renaming classes used in multiple projects, there are fundamental limitations, since an unopened project does not "know" what happened to a class also used in another project.  If one can reasonably create a project with all callers, that works, but that isn't always practical.  Putting classes in project libraries helps (the library, shared between projects, tracks changes internal to it, instead of multiple projects), where this is appropriate.

[GregFreeman]

Wow, I'm glad this sparked so many responses. To be honest, I never switched to file view except when I hit ctrl + e while the project was selected by accident instead of a VI  . I think some of these methods listed above will be fine for what I'm trying to do. In general, I'm not sharing classes between projects too often, except for reuse code which is unlikely to change, so that shouldn't be an issue. I will play around with some of these and see how they work. 

[bsvare]

Okay, I had to create an account to answer this. My company uses this stringent requirement to part number everything, including each individual class. As such, each class folder contains its part number. There have been plenty of occasions where the number I get is already used and I wasn't informed until after the class was developed. As such, I can and often do have a class and around 50 Vis that I'd have to move.

 

 

I use to try by windows explorer, but could never get it to be pretty. Then I discovered the Files view.

 

Original view:

 

In here, I select the class and all its member VIs. Right click, and Select "Move on Disk..."

 

I then find where I want to move it to, create folder if necessary, and select "Current Folder"

 

It'll take LabVIEW a few seconds to process simple moves, to about a minute for really complicated ones. It also relinks every VI call. (If in memory)

Afterward, it shows properly as moved:

 

This has literally saved hundreds of hours vs trying to move each individual VI one at a time. We also compile our code into lvlibp libraries so other functions that would call it, calls the packed library instead. That's why we won't have issues with external "non-loaded" code attempting to find new location.

[Neil Pate]

My solution is to never, ever rename classes. I'm serious.

Man, I hope I never have to debug any of your code. 

 

A class (or VI) name should reflect what it does. I feel it is not really acceptable to compromise on this just because the IDE chokes sometimes when doing these kinds of modifications.

[Mads]

Renaming a folder holding a class with Windows Explorer is no problem, because you can afterwards open the class and LabVIEW will find the right VIs relative to the path of the *.lvclass files. Even opening a project file will ask only once where to find the class. 

 

It should work as you describe it yes, but even when it is done like this, LV often fails to re-link everything. I've ended up with corrupt class errors (it might ask where the class file is, but fails to recognise it even though I know it is the same file, just in a folder that has gotten its name changed).

 

That's why I posted this on the idea exchange.

[unicorn]

@Mads

 

If one does two steps at once (rename class and rename folders outside LV IDE) you run into trouble. I often find myself in the situation to do to much in one step.

 

 

When having renamed a class outside of a project, I wonder if it would be possible that LabVIEW IDE tries to relink everything assuming that the new class (which the user selects as a replacement) is designed like a child class. I think you rename a class but you wouldn't change class VI names like "init", "get property XYZ", "calculate abc", "uninit", ... So LV IDE could find the right class VI for replacement in the new class. Of course new classes have new functionality. But no one can guess how and where to use it except for the architect and programmer. So new functionallity has always to be updated manually. 

[MikeC3]

Back on the SCM side for a sec, I haven't tried it, but I have read in documentation about a "repair file rename" feature that will make things happy on the SCM side if the files are renamed in your IDE.  I'll have to try that next time...

[unicorn]

Currently I am also in the nightmare of replacing a class by another class. This time I am switching to packed library.

 

I found that

 - that you can also make the old class inherit from the new class to replace all class VIs at once ( without "find and replace", just by replacing the first class constant/Control)

- you can use copy and paste on the front panel from the controls and terminals of the class

- LabVIEW IDE can switch instantaneouly from a class in a library to a class in a packed library (function available from context menu of a class in a lib)

 

So I see no reason why NI should implement a feature "replace class by anóther class" easily. Of course you would have broken wires if the new class does not have the right class VIs or if their connector panes are different. But this is trivial and up to the programmer.

[PaulL]

Following up:

 

In post #11 I talked about renaming files and source control management.  (How are people doing quotes on LAVA these days?)

 

Anyway, I found out from our Git expert that Git is smart enough to recognize renaming automatically.  I've checked in a couple renamed files and, sure enough, Git recognizes that the new file replaces the old, so that it is possible to track the full history.  That helps!

[unicorn]

As far as I understand, GIT detects this by  some (MD5?) hash value. So if you change the name and the VI itself (recompile, change in the block diagram, ...) at the same time, the history will be broken. But you can commit changed inbetween.

 

Anyway, you can add a comment to have a reminder if you do some major restructuring.

[todd]

TortoiseSVN's "repair move" works, but it's a manual process. In the commit dialog, right-click the "missing" file and delete it. Select both the deleted (old name) file and the added (new name). Right-click and select repair move.

[John Lokanis]

This topic is one of the reasons I gave up on source code control for the early stages of a project.  I have reverted to the 'zip and copy to server once a day' method for backups.  Once the project is stable and working, I will put the whole thing into Perforce for future maintenance.  But at this point, I seem to rename 50% of my classes as I code them and decide they need to do something different or need to be split into multiple classes.

And don't get me started on how I should have designed it on paper first so I didn't have to rename so many things.  I went into this project with exactly those intentions and I now believe that anybody who says they actually do this successfully is lying to you.

[drjdpowell]

This topic is one of the reasons I gave up on source code control for the early stages of a project.  

I just rename them and let the SCC record the old class as deleted and the new one created.

[Neil Pate]

I just rename them and let the SCC record the old class as deleted and the new one created.

Yup, rename inside LabVIEW and let the VCS tool worry about tracking the file-system changes.

[PaulL]

I just rename them and let the SCC record the old class as deleted and the new one created.

OK, but that means if you click on the new class (or class method) and look at the history, the version control provider will only show the history of the class (or method) after the rename.  If you need the history for some reason (and there are reasons, for instance to research when you added a feature or fixed a bug, even if you don't want to revert to an old revision), that's not a good thing.  It really depends on how often you need to look at the history.  For me it's not a major issue, but it is an issue (I consider it to be clearly a bug), and, for the record, I think NI should fix the issue (properly deleting from disk in projects: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Restore-quot-Delete-from-Disk-quot-in-project-Files-view/idi-p/1270866).  Full integration with version control providers absolutely requires it.  In the meantime I will hope for the best with Git's auto-rename-detection or Subversion's repair move, although these are don't always work.

 

Paul

Edited December 18, 2013 by PaulL