Why does LabVIEW allow me to have 2 controls with same name

[lmtis]

Where this can be a pain is if you are using invoke nodes to read the value of a control or indicator in another VI.  If you don't know there is more than one with the same name, you don't know where the data is coming from.

[LabViewGuruWannabe]

There may be a bug with multiple controls with the same name when using local variables in 8.5. I posted this to the forum: Local vairables with same name bug?

Interestingly, in 8.2 the list for local variables is in tabbing order, but in 8.5 it seems to be alphabetical.

B-)

[Matthew_Kelton]

---

@lmtis wrote:
Where this can be a pain is if you are using invoke nodes to read the value of a control or indicator in another VI.  If you don't know there is more than one with the same name, you don't know where the data is coming from.

---

This is why TestStand does warn you if you are trying to call a VI with two controls/indicators with the same name.  It is very possible for LV to pick the wrong control or indicator.

Message Edited by Matthew Kelton on 12-19-2007 12:21 PM

[lmtis]

This brings me back to the original posters complaint.  Why do you need an extra $4K application to tell you that you have two variables with the same name? God knows it is enough of a waste of money trying to keep up with the continual "upgrades" of the developement system.

[Matthew_Kelton]

You don't need TestStand to do it.  You can create your own VI to determine if you have two controls with the same name.  Posters in this thread have already posted the guts of the code to do so.  LabVIEW doesn't use the name to identify the variable, it uses some internal reference.  So the name of a variable doesn't have to be unique.  As others have shown in this thread, they have uses for the "feature."  I use it because I tend to not like the "refnum in"/"refnum out" standard that everyone uses when passing data through a VI.  I rarely use local variables, especially in this case, so I have no confusion as to what is what.  When I use VI Server and TestStand, I make sure that my variable names are unique.

The only place you should EVER be in a situation where you can get confused is in a GUI app.  A subVI should never have so many variables you can't kep track of them.

[smercurio_fc]

I suspect Jim may have just been blowing off some steam regarding "seemingly constant" upgrades.

[altenbach]

Let's not forget that LabVIEW even allows you to have multiple controls or indicators without a name (zero characters). 😉

[shoneill]

Altenbach wrote: "Let's not forget that LabVIEW even allows you to have multiple controls or indicators without a name (zero characters)."

That's a great idea for prohibiting the use of local variables.....



Shane.

[lmtis]

On a certain level you are of course correct smercurio.  I can find no reason to talk my company into spending the money to purchase newer versions of LV, and this leaves me getting further and further out of touch with what is happening.  It also means that I cannot look at many of the examples that are being produced by the community . With regard to the topic at hand, Matthew picked exactly the type of app where I ran into a problem.  I was editing a VI that neede to pull data from a GUI app.  I created a control on the GUI and tried to poll the value of the control with an invoke node.  It took an inordinate amount of time for me to figure out that the reason it wasn't working was that there was a boolean indicator on the GUI with a hidden name.  A name that was exactly the same as my control Altenbach is of course correct that this can never be disallowed now due to the amount of legacy code that would be broken, but it IS an annoyance when you get bitten.  I understand that the language doesn't use the names as a reference, but that is inconvenient when the name is the primary reference that the programmer has to keep track of them.