LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Here's a general LabVIEW question:
Why does LabVIEW allow me to have 2 controls with the same name in the same VI?  It seems like this only increases the chances of confusion.  Especially when someone is just looking at a block diagram (or documentation of a block diagram).
 
 
No other programming language that I know of allows this.  I realize that uniqueness of name is not as critical in LabVIEW as it is in any text based language.  For example, in a text based language, if I had 2 variables called abc and I wrote a statement
abc = 12;
the compiler would not know which abc was being referred to.  In LabVIEW, if we had 2 controls called abc, the equivalent of doing an abc=12 is writing to a local variable (which is always linked to one of the controls) and there is no ambiguity.  Still, someone looking at the code cannot figure out which abc is linked to unless he does a right click>>Find>>terminal (or a double click).
 
Even though I have never and never will name 2 controls the same, I think it would be a nice constraint to see enforced by LabVIEW.
 
Any input from NI engineers on this?


Message Edited by S G on 12-18-2007 03:38 PM
S G
Certified LabVIEW Architect, Certified TestStand Architect, Certified Professional Instructor
Message 1 of 33
(6,241 Views)
Sometimes this can actually be a benefit. I've often exploited this "deficiency" (though I wouldn't call it that) when replacing typedefs.
Message 2 of 33
(6,214 Views)

I've often exploited this "deficiency" (though I wouldn't call it that) when replacing typedefs.

How?

 

S G
Certified LabVIEW Architect, Certified TestStand Architect, Certified Professional Instructor
0 Kudos
Message 3 of 33
(6,204 Views)

Although I would not use duplicate names for any controls, I can see having controls of different types with the same name.  Like a string called abc and a numeric called abc.  But to have two controls of the same type have the same name could lead to lots of confusion.  I agree that NI should not allow this.  Well I guess it is easy enough to just not do this yourself.

- tbob

Inventor of the WORM Global
Message 4 of 33
(6,201 Views)

Crazy app, but you could have a tab control with a number of pages.  On different pages indicator that have the same name and display the same info.  Using references from tab property node, you can search by name to get the control ref num and send data to all indicators of same name but on different pages.   I won't go into details, but it is a feature that can be exploited 🙂

 

Message 5 of 33
(6,193 Views)

I am not sure that it should be up to LabVIEW to disallow multiple controls/indicators with the same name. If they would suddenly enforce this, it would break a lot of old code.

I agree it can lead to horrible confusion if you are using local variables in such a scenario, but the overuse of locals is bad in general. It is incorrect to use local variables as a substitute for "variables" in text based code.

I believe the VI analyzer will tell you if names are not unique.

Message 6 of 33
(6,183 Views)
I know when you copy and paste a control or indicator, LabVIEW automatically increments the label. But since you can hide the label, and show or hide the caption, there must be another mechanism that LabVIEW uses to keep track of all the controls. I thought I remember back in the "old days" (ver 6 or 6i) LabVIEW would give you an error if you tried to make two controls with the same name. Perhaps that was LabWindows/CVI.

I don't know where the index is actually stored, but if you look at a property node linked to the Pane, you will see an array of references to the controls and indicators. Since the references are stored in an array, I assume that any local variables are tied to the index of that array. Since the labels themselves are properties of the control, I guess there's no reason to limit what that label is. They all have a unique index number.

Interestingly, this array of references grows from the beginning. That is, any new control or indicator is put at index 0, not the end of the array.




B-)


Message Edited by LabViewGuruWannabe on 12-18-2007 08:45 PM
Message 7 of 33
(6,168 Views)


@S G wrote:

I've often exploited this "deficiency" (though I wouldn't call it that) when replacing typedefs.

How?



Usually when I drag and drop a typedef onto a VI that has a typedef I need to replace. I'll place the new typedef onto the VI, copy the label from the old, and replace the name on the one I just placed (essentially giving me 2 controls with the same name), cut the new typedef, and paste over the old. Sometimes this is faster than right-clicking on the typedef and selecting "Replace" and then navigating to where the new typedef is.
Message 8 of 33
(6,121 Views)
@ LabViewGuru...
> Interestingly, this array of references grows from the beginning. That is, any new control or indicator is put at index 0, not the end of the array.

I checked with LV 7, the order I get the controls is the tabbing order (Edit->Tabbing Order).
I used VI.FrontPanel and Panel.Controls[] properties for this.

Felix
Message 9 of 33
(6,112 Views)
Felix is correct. I see the same thing in 8.5, as far as the VI.FrontPanel and Panel.Controls goes.



B-)




Message Edited by LabViewGuruWannabe on 12-19-2007 11:20 AM
Message 10 of 33
(6,079 Views)