Path as part of the VI file name

[Freeky Frank]

Is it possible to make LabView use the VI path (or part thereof) as part of the VI name?

I can here you asking why?

Simple I like to use meaningful VI names and I have a project with a large directory tree. In earlier versions of LabView the path and duplicate files were ignored if the file was found as expected. So with care it simply worked.

Now with more complicated project management LabView bitches about files with the same name and makes me select the correct one. As a result I am becoming more paranoid about ensuring LabView gets the right file. If the path from the project base was considered part of the file definition this would not happen and many files, if in differing directories, could have the same name without any problems.

This would make the programming model more like a conventional language in that the location of the file is considered part of the file definition.

[JeffOverton]

You cannot use operating system characters like / or : as part of a filename for any windows object.

[Freeky Frank]

JeffOverton said

>> You cannot use operating system characters like / or : as part of a filename for any windows object.

Sorry Jeff, I understand what you are saying but you missed my point. I was referring to the code management, interpreter side of LabView not the user side. So the file names would stay as they are for the user and he/she can reuse file names in differing directories with impunity. However, LabView would understand the files as being part of a directory structure and not complain when the file name is used again elsewhere.

[JeffOverton]

Oh, sorry, I see what you mean.  I'm a lot less helpful on that question because I've never found a way around it except nomenclature.

[smercurio_fc]

That would require a pretty fundamental change to LabVIEW, and I don't see that happening any time soon. The reason for the disallowing of 2 VIs with the same name has to do with the way LabVIEW manages VIs in memory. It goes by the VI name. Thus, you can't have 2 separate VIs with the same name loaded in memory at the same time. Your best bet is to adopt a naming scheme that uses prefixes to indicate with which component/subsystem/whatever a VI belongs to. For example, you can prefix all utility-related VIs with "UTIL" and have the name on disk for the file to be "UTIL - <VI Name>"

[Ray.R]

If you consider the project manager to be complicated at handling similar named vi's, imagine the complex can of worms if you'd have dynamic names 😄

Have you considered Configuration management tools for revision control?

[Freeky Frank]

Morning, thank you for your replies, you have confirmed my opinion of the status quo.

Project Explorer already has to understand the directory structure to be able to find the files so why can’t it take the information already processed and encode it into the “file name” it uses as it loads the VIs into memory. Make the name used for each VI relative to the projects base; I could code this in about six lines of C or Perl.

Job done!

Yes, I know I simplify but it’s not a lot worse than I have said and it would make life so much simpler. Rewriting VI that could be the same but for file name changes and label changes is bad. Yes! I do use re-entrant code but it is not always possible.

Oh well back to work, I have about fifty Vis to rename and relabel this morning because of a small change in project structure. It’s not even as if I can use a text editor to do repetitive tasks like this because the source files are binary encoded.

[Ray.R]

Just curious:  Is it actually necessary to change the names of the vi's?  It's not totally clear to me why you want to take that route.

[Freeky Frank]

JoeLabView Asked:

>> Just curious:  Is it actually necessary to change the names of the vi's?  It's not totally clear to me why you want to take that route.

Joe

Sorry for the delay I have been away on holiday for a few days looking at Castles and the like in Jersey (UK).

To answer your question the only reason for changing the name of the VIs is that LabView complains when it has two VIs with the same name even when they are in differing directories. This is what started the chain.

I am sorry I have just reread the chain and I cannot believe I did not explicitly say this sooner.

[Ray.R]

Yes, multiple locations for same-name vi's has always been troublesome.

From experience, there are two reasons why I would have same-name VI's:

1) Multiple instances of the same project.  This is when you want to "keep" a version of the project frozen, while doing some changes to a copy of the same.  If you have CM tools, this is where you would check in a baseline and check out a copy to make changes.  Thereby having only 1 copy on HD.  Alternatively, if you do not have CM tools, always ZIP and properly name the zip file which contains the version you want to keep as a baseline. 

In other words, only have 1 active copy at all times.  You do not want multiple instances of VI's having the same name. 

2)  A VI is used by multiple projects.  That's when I add it to a library and it is located at only one location.  All projects point to the same one.  If additional features are made to the VI, I would then rename it.  Again only unique names.

Managing names of VI's is an important step in the deign / development process.  I'm quite sure we all crossed that bridge 😉  Some more often than others (speaking of myself 😄 )

Constantly changing names of VI's may not be a good long-term solution because it becomes quite difficult to keep track of which one you want if you plan to reuse the VI.  That's where building libraries becomes useful.

🙂