DQMH renaming tool problem

[1984]

Hi,

In my project I have a Testpanels.lvlib which has some of the DQMH modules I display to the user (as well as some other VIs). I have created a "StatusBar" module, which works without any problem, but I figured that it would be better to call it "FooterBar". I have started a DQMH module rename which actually never finshes renaming the module.

As you see in GIT couple of files (I guess) having labels saying StatusBar appear as unstaged. The DQMH rename tool changes those label to say "FooterBar" at this point the process start to hang and doesnt finish, not even in 30 minutes.

What I have tried several things:

• killing LabVIEW from the task manager: This immediately floods the unstages files window showing so many file changes which are not releated at all to this module. No calls from/to in those files.
• running the DQMH validation tool shows no problems with the module
• tried to rename a different DQMH module in the same TestPanels.lvlib -- ???????????
• I knew for sure where the StatusBar module is used in my project. Removed all the VI calls from the module, tried renaming, no change
• I have a Framework.lvlib which also has DQMH modules and other VIs mixed. The renaming tool could rename a randomly picked module from this lvlib, although also caused gazillion filechanges all across the project.
• I have removed the StatusBar module and tester from the TestPanels.lvlib and moved directly to the project root. Didnt help, renaming does the same: it quickly changes couple files but then just seems to hang.
• I have completely removed the StatusBar from the TestPanels.lvlib and even from the project. I have moved it to a different path outside of the project folder. Created a project which had only this module and started the renaming tool. Rename finished without hanging but the name of the module didnt change. Running the Validation tool shows that the labels were renamed to FooterBar, with the exception of the Obtain request Events.VI. 
  • After this I have manually renamed the StatusBar.lvlib to FooterBar.lvlib and did the same with the API tester
  • Also fixed the Obtain request Events.VI label
  • At that point I have a fully functional FooterBar.lvlib module
  • Staying in the same isolated project I tried renaming the FooterBar.lvlib module to something else... still showing the same problem

I'm wondering if there is something I can try besides these or if you guys have any idea why do I see  this behavior. Again, for some modules renaming works OK.

Thx!

EDIT: I'm using a custom DQMH module template and I have just noticed that even if the template passes on all the Validation tests if I create a new module based on this template I can't rename it. I have two templates - one for Singleton and one for Cloneable - both show the same behaviour. I have no such problem when renaming the standard Singleton and/or cloneable modules. (???)

[1984 · Accepted solution]

I started to roll back my module templates in GIT one commit at a time as I remembered that there was a time when I was able to rename modules created from my template without an issue. By the way God bless whoever invented version control.

After going back couple versions I reached a commit which didnt show the problem. I checked the changes and found this:

In my template I wanted to give the developer an option to change the module name thru a request. To do so I have modifed the Module name--constant.VI. I dont think that the modification is interesting, but nontheless this caused the problem I experienced.

It is 100% reproducible. Create a module from the stock Singleton

1. go to this VI and put another string constant to the block diagram and save the VI. With this the renaming works (even the lvlib changes name) but if open the Module name--contant you'll see that the new module name is in the new string constant.
2. Copy the output terminal (no need to do anything else) and save the VI. Now if you try renaming the module you'll see the behaviour I have described in the topic
3. Change the VI back to the original, rename works again.

Even when I have changed this VI I was wondering how the DQMH script knows which constant to change because it doesnt have the typical DQMH<this or that> label. But didnt care too much because I've seen that once I create the module the constant changes (I didnt use other string constants on the BD).

Yes, you are right! Maybe I shouldn't have touched a VIs called 'constant'. But I did, because its not documented that it could cause such issues. During the rename absolutely nothing indicates that this is a problem so I would consider this as a bug. 

Good 8 hours of my work is gone, but on the bright side I only need to change that VI back to the original in all the modules I have created after that given commit (which is super easy) and I get things back on track.

After I get all the blame, kudos to me I guess. 

[Darren]

This bug has been reported to the DQMH Consortium as Issue #835. I'm not sure the best way to go about fixing it. The string constant in the --constant VI could be tagged as you described, but that would only help with the issue going forward. I guess a Validate+Fixer tool could be added to tag old code, but it would also need to notify you when it can't automatically fix the issue because there are multiple string constants.

Anyway, thanks for reporting the issue and providing a detailed description of how you solved it. Kudos from me.

[1984]

The screenshot above shows the problematic part of the Scripter - update module name in VIs.vi

Patchwork #1: 

Replace the shift register of the error cluster by a tunnel:

- If there is only one string contant on the BD of the module name VI then this works fine

- If there are more than one then it will change the content of the most recently placed constant

Patchwork #2:

one can have as many string constants on the BD if these steps are followed:

1. after your modifications of the VI save it
2. Delete the string constant having the module name with Ctrl-X
3. Resave the VI
4. Paste the constant back with Ctrl-V (plus wire it back to the output)
5. Resave the VI

This puts the constant to the first place in the All OBJ array so the for loop above finds it at the first iteration.

These are not THE solution to the problem, but work as a hotfix until the problem is properly addressed.

Besides this another problem is that Save.Instrument VI is inside of the for loop (not show in the screenshot). This means that if prevous operations (Renaming labels in other VIs) finish successfully then their changes got saved so the labels will reflect the new module name while the renaming process ultimately fails rendering the labels and the module name to be inconsistent.

To address this below is another quick fix which at leasts doesnt save the VIs if an error occured. I dont consider this one as a solution either: