Jump to content

Best Practices Question - Renaming Source Files

Recommended Posts

So way back in the day (VIPM 1.x, 2.x) renaming of the source files in a build was required to build a package.  The build process required that the built package would have VIs that had a prefix/suffix added.  So a VI named "Do Super Cool Stuff.vi" would have to become something like "Do Super Cool Stuff_Hooovahh.vi".  Because of this I've just continued to add a suffix or prefix to all my source VIs for all packages I've built.

However I've ran into problems where the renaming might break things, or cause weirdness.  So in some cases like QuickDrop Plugins, or Tools Menu items, I've turned off the adding of the suffix and things work fine.  I've also realized that if I have a package that contains a parent class, and I create a child class as a separate package, then I can't perform the rename, since overrides will be looking for the child class to have the suffix.  So a parent VI of "Parent:Find Hardware_Hooovahh.vi" will look for an override with that name and not the source name of "Child:Find Hardware.vi".

So with all this being said, should I perform the renaming at all?  Should I go through all my reuse libraries and rebuild them all, removing the suffix?  If I do that I'll likely need to write some scripting code to replace all the calls of the suffix with the one without.  Is there any real benefit to having the rename when there are clearly draw backs?  Thanks.

Link to post
Share on other sites

Great Question!

I hope JKI provides some guidance with regards to how they intended these tools/options to be used.
However, I doubt there's a one size fits all answer.

My reason for adding suffixes is to prevent cross-linking of VIs in my VI Packages source code to those same VI in VI Packages used in my projects (Conflicts that cannot be resolved).  When I'm adding functionality to the Quick Drop or Tools menu, I typically don't set them to be renamed.  And, I have had problems and needed to rebuild VI Packages after realizing I'd forgotten to uncheck the renaming for dynamically called VIs that were not found after a suffix was added.

If your tools development is always separate (different PC) from any project development using the VI Packages, you likely don't have to use renaming.

Well, that my nickels worth.

Link to post
Share on other sites

Hi Guys,

That's a bit tricky and depends...

The point of adding a name suffix is because LabVIEW has historically done a poor job of preventing cross-linking of files -- there was a global namespace for all VI's in memory. Since then (and recall that VIPM has been around for over a decade) LabVIEW added lvlib (and lvclass) files to help with namespacing.

I'd say that the #1 use-case for adding the suffix/renaming is that when you're the developer of a tool, the installed version of that tool can mess up the development version of the tool.  Of course, with the suffix/renaming you can get into situations where the source version of the tool accidentally links to the installed version, if you're not careful (since the installed versions will be in the palettes).

As @HB65093 mentioned, when you're creating a Quick Drop, Project Provider or other LabVIEW plug-in, sometimes the renaming gets in the way of things working properly.  And, as @hooovahh mentioned, the renaming messes up dynamic dispatch calls, since the VI name is critical for LabVIEW to identify the override methods.

For me personally, there are many cases I do not add a suffix/prefix during the build process, but I usually leave this setting ON by default unless I want it OFF.

@hooovahh - have you had any problems *not*  adding the suffixes? If not, then it's probably not a problem.

I'm really enjoying hearing from you all about what works well (or not) and why!

Link to post
Share on other sites

I always defaulted to using the renaming, and only turned it off in rare cases when renaming broke things.  So for me on those rare occasions where I didn't rename, things did work fine.  I've been pretty mindful of cross linking and avoiding it between source and install.  Given that the only major reason to use rename is to avoid cross-linking I'm going to try to undertake a change to have everything non-renamed.  I want to be consistent one way or the other and it seems there are cases when renaming breaks things, but I'm unaware of any case when not renaming breaks things (other than cross linking which can be avoided).

My major development woes with this is going to be having a VI that used to call something like: <user.lib>\_Hooovahh\<Package>\Name_hooovahh.vi is now going to have to be updated to point to the Name.vi instead.  I have some scripting code to help with this which can return the expected missing VI path, but this doesn't seem to work for VIMs.  I already posted over on NI's forums here.  Until I get a solution it will be lots of manually fixing VIs and rebuilding...then fixing all the active projects.

  • Like 1
Link to post
Share on other sites
  • 2 months later...

Okay so personally I've come to the conclusion that I won't be using suffix or prefix anymore.  If you are going to use renaming, use suffix.  Prefix makes viewing all files sorted by name do unexpected things if it is mixed with files that aren't renamed.  I also sometimes type the name of the function I'm looking for in Windows and if you add a prefix now you need to type "hooovahh_" before everything.

So we've already mentioned reasons to not use suffix renaming.  QuickDrop, Right click, and other NI frameworks rely on some naming conventions sometimes and these break.  OO override issues, you must have all children classes, in the same package as the parent class.  Otherwise overrides won't work until it is installed.  So a demo or example VI in the child class will be broken until it is installed if it uses the parents override.

But I have another new reason.  I had one package that was 16MB in size and was too big.  So I moved a bunch of stuff into it's own package.  Well the source expected to find all dependencies without the suffix name.  Since it was previously in the same package.  But now the functions it calls is in the installed location and the VI names aren't the same.  It was looking for the VI names without the suffix, but now needs the VI names with it.  This means replacing every VI, VIM, control, class, library, XControl, and every dependency.  Scripting helps but still is a pain.  If I was never using suffix naming then it would just look for the VI names and loading the installed VIs into memory first, would mean the new package finds the source in memory where I want and a Save All will update code to use the installed location.

And I hope it is pretty obvious changing from using suffix, to not can be a major pain if your libraries are as large as some of mine are.  This also means updating all active project, replacing all dependencies to the new ones...also painful.

Jim is right that more consideration needs to be made when editing package source to make sure it links to the installed locations of other dependencies.  But editing one package at a time can help with that.  And I've seen VIPM gracefully fails to build if a dependency is outside of the source.  Once built and tested all is good.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.