LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
lsn

Opening two VIs with same name

Status: Declined

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.

i have faced this problem many a times. Suppose I have a main VI opened and if I have a subVI (say sample.vi) in the main VI and I try to open another VI of the same name as subVI , then the subVI in main VI will get replaced with the second subVI. Labview should take care that any VI should be referenced with the complete path and just not the VI name. 

 

7 Comments
Mads
Active Participant

Are you working in LabVIEW 8.X and do not like the way this is handled there, or is your request based on use of previous versions?

 

This was at least partially (perhaps as well as it can/should be) solved with the introduction of Projects (LV 8). You can have copies of the same VI opened if they are in separate projects...and within projects you will get a conflict warning and (in some cases) the option of resolving this.

 

Intaris
Proven Zealot

Aside from the multiple project situation I don't think this is going to happen any time soon.

 

NI uses the name as a unique identifier within the LV code (I believe AQ mentioned this in conjunction with a LVOOP Issue).

 

This would mean making changes deep into the core of LabVIEW which is something which probably won't fill the R&D team with joy.

AristosQueue (NI)
NI Employee (retired)
More than the burden of work on us, it would introduce usability problems for you, our users. There are many programs that load different versions of the same VI depending upon conditions and then load callers of that VI, expecting the callers to link to whichever version is in memory. Generally these are apps developed before the introduction of LabVIEW classes (which handle dynamic plug-in loading rather more elegantly), but we couldn't just change them. Also, if we did save based on tight binding to path, and then you did move a file on disk, it would be substantially more work for you to *fix* broken VIs. For each caller, you would have to browse to the moved VI, as opposed to loading the moved VI into memory and then opening all the callers and having them find the VI already in memory.
AristosQueue (NI)
NI Employee (retired)
Another reason we wouldn't make this change:

Having two VIs of the same name is really confusing when you're talking about a VI and describing its functionality ... You have two subVIs named "Init.vi". Which one is this caller VI invoking? Oh, it's calling the DAQ version of Init.vi, not the GPIB version of Init.vi... Hey, idea, why don't we name them DAQ_Init.vi and GPIB_Init.vi? Wow. Oh, we want the same file name so that everyone knows where to find the initialization routine? Ok... that's what libraries are for. We put the DAQ API into DAQ.lvlib and the GPIB API into GPIB.lvlib. And now we have DAQ.lvlib:Init.vi and GPIB.lvlib:Init.vi. We can go further... let's make Hardware.lvclass, give it an Init.vi, and then create child classes DAQ.lvclass and GPIB.lvclass, each of which override Init.vi with their particular implementation. 

 

That's for the cases where the two subVIs are meant to be used together. But, on the other hand, maybe you really do have to independent applications that you want to run at the same time and they just happen to have two identically named subVIs. The solution there? Projects. Every project is an independent application instance. You can open C:\A.vi in one project and D:\A.vi in a separate project, and they'll happily both be in memory simultaneously, each running in its own little LV sandbox. 

 

The desire to have two identically named VIs is a false desire. It creates as many problems as it solves, and rather than do that, NI provides three different features to avoid the need for this entirely: Libraries (namespaces), Projects (application instances), and Save As:Rename.

LabBEAN
Active Participant

Isn-

I mean no offense by this post, but I didn't intend to give Kudos here.

 

Kudos Counters-

I center clicked the "who gave kudos  to this post" link and it opened a new tab (expected) and took me to a screen that listed me as one of the supporters (unexpected).  I think there might be a bug here.  Using Firefox 3.0.11


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
GPIB_Guru
Active Participant
It would be nice for diffing.. I have v1 of the VI and v2 of the VI. Same name - what changed? Don't know unless I rename the first one - which sucks if you are comparing hierarchies.
Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.