LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why are lables not forced to be unique?

For what reason(s) does LabVIEW allow two or more controls to share the exact same label?  If you want a number of controls to share the same name on the FP, isn't that what the caption is for? Other than winning a code obfuscation contest, I cannot see a valid reason why I would want two controls on the BD share the same name.

 

dupe_lables.gif


Message 1 of 21
(3,026 Views)

Because control references (and UIDs) will be unique for every object in memory, why should NI put this limitation on code?  

 

Is it bad coding practice to have the same label for two controls?  Yes.  But there are many things that LabVIEW has that is bad coding practice that NI leaves.  One could argue that native Global Variables, and Sequence Structures are bad coding practices and NI should also remove these features.

0 Kudos
Message 2 of 21
(3,014 Views)

Yeah, in my opinion, LabVIEW should force to not have repeated labels. And actually when you created a new object on BD or FP, LabVIEW always try to give a new and unique name (say if already there is a numeric control with label 'Numeric', next time when you'll create, LabVIEW gonna give a label called 'Numeric 1').

 

And internally LabVIEW uses, something called UID (Unique ID) to differentitate different controls/indicators.

 

UID.png


I am not allergic to Kudos, in fact I love Kudos.

 Make your LabVIEW experience more CONVENIENT.


0 Kudos
Message 3 of 21
(3,011 Views)

> Is it bad coding practice to have the same label for two controls?  Yes.  But there are many things that LabVIEW has that is bad coding practice that NI leaves.  One could argue that native Global Variables,

> and Sequence Structures are bad coding practices and NI should also remove these features.

 

I still see a distinction here and that is I can see zero valid uses (other than purposful obfuscation) to allow them to share a common name.  I'm sure I could come up with a reasonable use case for the two you mentioned; certainly sequence structures.

 

The UID under the hood explains the how it works, but I just cant see the justification for the why it's allowed to work.


0 Kudos
Message 4 of 21
(3,000 Views)

Some more info:
http://zone.ni.com/reference/en-XX/help/371361J-01/lvscript/gobject_uid/


I am not allergic to Kudos, in fact I love Kudos.

 Make your LabVIEW experience more CONVENIENT.


0 Kudos
Message 5 of 21
(2,997 Views)

@Hooovahh wrote:

Because control references (and UIDs) will be unique for every object in memory, why should NI put this limitation on code?  

 

Is it bad coding practice to have the same label for two controls?  Yes.  But there are many things that LabVIEW has that is bad coding practice that NI leaves.  One could argue that native Global Variables, and Sequence Structures are bad coding practices and NI should also remove these features.


I could find legit uses for each of those examples, but it's hard to justify a behavior that has no known advantage but would cause only confusion and heartache...

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 21
(2,994 Views)

@billko wrote:

I could find legit uses for each of those examples, but it's hard to justify a behavior that has no known advantage but would cause only confusion and heartache...


Except if confusion and heartache is what you were after.  I think that would be a fun excercise for obstrufication, write a scripting VI that will rename all labels to the same value, call it "value".  Also replace any constant labels with "value" as well just for good measure.  I'm quite certain that other companies (I'm thinking JKI) has made code obstrufication VIs.

 

And for the record I think it is a bad idea to have multiple controls with the same label, I just don't know why it would need to be changed now.

0 Kudos
Message 7 of 21
(2,985 Views)

@Hooovahh wrote:

Because control references (and UIDs) will be unique for every object in memory, why should NI put this limitation on code? 


This is a valid point that I didn't address in my previous post, so let me do that now. 

 

NI has already set a precidence of putting limitation on code for the betterment of the community and best programming practices.  You need look no further than LabVIEW classes, you are forbidden to make any members of the class have public scope.


0 Kudos
Message 8 of 21
(2,984 Views)

@SeanDonner wrote:
 

NI has already set a precidence of putting limitation on code for the betterment of the community and best programming practices.  You need look no further than LabVIEW classes, you are forbidden to make any members of the class have public scope.


Sure but again NI gave me the tools to use public or private methods where I can expose all the data related to my class, in public methods.  They also hint that having multiple controls with the same label is bad, by renaming new controls to not have the same name, but still allows me to have the same name if I wanted.

0 Kudos
Message 9 of 21
(2,974 Views)

The comments to this idea probably has some controbutions to the discussion.

 

I am OK wilth allowing duplicate labels. If you are worried, there is a VI analyzer test that checks for duplicate labels. 🙂

 

Else where would you want to draw the line??

What if you have two different typedef'd clusters, each containing an element named "coordinates". Should LabVIEW break the VI? Probably not!

If you have an array, all elements have the same label.

Message 10 of 21
(2,961 Views)