Why are labels not forced to be unique?

[SeanDonner]

---

Else where would you want to draw the line??

---

I think the line in the sand would be pretty distinct.  You are not allowed to have duplicate names for "top-level containers" in the same BD.

[altenbach]

Of course such a new rule, if implemented, would break a lot of legacy code.

[RavensFan]

Block diagram objects all have labels, though they are usually hidden by default.  Drop a For Loop and show the label.  You will see it is "For Loop".  Drop another and show its label, it is also "For Loop".  Should these be forced to have unique labels also?  SubVI's are block diagram objects that also have labels.  Should they be unique when you drop multiple copies of the same subVI?

Controls aren't really that much different than other objects either on the block diagram or front panel that possess labels.

[Darin.K]

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

Elements are namespaced by the cluster, I don't see this as an issue.

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

LV considers the label to be part of the datatype.  An array is a collection of elements of the same datatype, therefore the same label is assumed.

Of course such a new rule, if implemented, would break a lot of legacy code.

A lot of restrictions, such as this one, should be enforced by the IDE, not the compiler.  That means that code would not break, you just couldn't do it anymore.

Controls aren't really that much different than other objects either on the block diagram or front panel that possess labels.

Controls have one difference, they are referenced specifically by their label on occassion.  Locals, references and the Get/Set Value By Name for example.

My objection is not with degenerate labels, but with degenerate datatypes (type + label).  That should be disallowed IMO.  I am ok with a string and boolean with the same label (and the Get/Set Invoke Node should use it as a tiebreaker).  The reason is my desire for LV to be a WYSIWYG language, meaning I could tell explicitly what the code is doing from an image, just like I can with an ascii representation of C++ code.  I should not need VI analyzer or the IDE for a code review.

[Intaris]

---

@Darin.K wrote:

 Of course such a new rule, if implemented, would break a lot of legacy code.

A lot of restrictions, such as this one, should be enforced by the IDE, not the compiler.  That means that code would not break, you just couldn't do it anymore.

---

It would break in the IDE, preventing you from compiling or even running that program ever again without "fixing" the "problem".

This is a non-issue as far as I'm concerned.  In over 10 years programming LV, I've never had a problem with this.

[altenbach]

---

Darin.K wrote:

Elements are namespaced by the cluster, I don't see this as an issue.

---

Well, you can create property nodes and references for elements in clusters and they will show up with the same name label if the controls are named the same inside the cluster (there is even a "solution" example in the CLD training material).

As with Shane, I don't have duplicate control name problems with my own code, but it occurs often enough in forum examples to get slightly annoying. I am just still not sure if anything should be done about it, and if so, what exactly?

An related problem is the fact that we are allowed to change the labels of references, property and invoke nodes so they differ from their linked control, something that could lead to equally confusing situations (That's why I wrote this idea long ago).

[Intaris]

He.

I just followed your link with intent on giving Kudos but I found out I had already given Kudos 2.5 Years ago!  That's long from being retained in my short-term memory.

How about a visual indicator that a node name is not unique (With a red asterisk or something) so that those who wish to eliminate them can, but the rest of us are essentially unaffected.  Certainly no broken code.

[RavensFan]

I'd argue there is a situation I see on uploaded vi's in the forums that is at least as bad if not worse then duplicate label names.  Those are the controls where there is no label whatsoever.  You have a terminal on the block diagram with no label.  You don't know what it goes to.  You click show label and find out it is blank.  Then you need to give it some sort of name until you figure out what it should legitimately should be called.

I'm not completely sure how some LV programmers are getting themselves into this situation.  Or why they don't care they have an unnamed terminal on the block diagram.  I suspect that they want to take away label on the front panel control, and instead of hiding the label on the FP, they wind up editing and blanking it out.  Bad, bad practice.

[altenbach]

---

@RavensFan wrote:

I suspect that they want to take away label on the front panel control, and instead of hiding the label on the FP, they wind up editing and blanking it out.  Bad, bad practice.

---

Yup, that's my guess too. And since LabVIEW does not enforce unque labels we can have more than one item without labels.

I guess part of the discussion would be to suggest to also disallow empty labels. Maybe it was already mentioned somewhere....

[Darin.K]

This falls somewhere in the murky depths of proper use (name withheld to protect the guilty):

I would like an option to drop a control on the FP with the caption ready for editing.  Then on the BD I can adjust the label (default = caption) to be more appropriate.  [Aside:  I would not bother to add default default values in parentheses.  error in (no error), no thanks.]  Property dialog, those things scare me, often end up with my windows being shuffled.

Empty labels:  Bad form, I'd let the IDE take care of that one too.