Update LabVIEW class controls and labels when class is renamed

[jlokanis]

When designing a application, I sometime find that I am not happy with the name I choose for a class after I have already integrated the class into my project.

I also often use the class name for the label on in/out terminals and block diagram constants of the class.

The problem arises when I change the name of the class from within the project.  If I then go inspect the code, I find that the labels still have the old class name.

For example, if I rename the class from 'My original class name.lvclass' to 'My new class name.lvclass' I still see this on the block diagrams:

But what I want to see is this:

So, I propose a rule.  If a control or constant of a class has its label visible and that label (or part of that label) matches the original name of the class on disk (with or without the .lvclass extension), when the class is renamed in the project, the label on the control or constant is also changed to reflect the new name.

The reason I say 'or part of the label' is if you have added a prefix or suffix (like 'in' or 'out') to the label, it would still get updated.

I also think that this should apply to labels that include the '.lvclass' and ones that do not, as I often will use the class name without the extension when labeling classes.

I am happy to accept that this correction would only apply to code within the project where the class rename happens.  But it would be a bonus if there was a menu option to rerun the cleanup from a different project that might use the same renamed class.

Thanks in advance for the Kudos!

[Intaris]

But only if the label is still the default of the old class......

[jlokanis]

Yes.  If the label does not match the original name of the class (with or without the extension) then no cahnges will be made.

[GregFreeman]

I haven't used this, but a tool already exists. Not sure if it does exactly what you want.

[jlokanis]

Yes, that does part of it, but it overwrites the name even if it is not the original class name.  And it does not fix block diagram constants.

[GregFreeman]

Ah, good call.

[PNR]

I like that idea very much, and would add one thing:

Do this also for strict type definitions.

[ToeCutter]

Don't like this idea - it works for some, but may screw things up for others who work differently. I wouldn't mind if it was optional and off by default. IMO, it's cleaner coding style to avoid repeating the class name in fields and constants and this circumvents some of the naming headaches.

[JrnBrgr]

renaming class terminals could be done with a little VI that search a project for a certain class, then you get a list where you can select terminals to rename and you enter the new name ...

[JrnBrgr]

I have uploaded an example here //decibel.ni.com/content/docs/DOC-33253. It works on front panel items only and can tolerate some improvements.