How Does LV work with the Same Label?

[Call_Me_Vinny]

I recently discovered that controls in LabVIEW can have the same Label.  I was astonished because I always believed the Label was a unique identifier for the control/indicator.  I started wondering what happened when you had two controls of the same name and you tried to set their values through VI server.....*

So I decided to test it. Turns out that (in my tests at least) the first control always seemed to get set.  So how would one set the second control?

I tried setting the control's value twice to no avail:

Is there anyway that you could accomplish this?

I'm starting to feel that this is really a bug in LabVIEW.  If the Label is going to be used by functions as an identifier (as the Control Value.Set method does) then they should really be a UNIQUE identifier.  Besides, captions can be used to if you need the Labels to appear to be the same.

For what it's worth, the test code I was using is attached.

*I do realize that this is not only horrible style, but horribly impracticle as well.

[Mark_Yedinak]

this is not a bug. The wire is the data. When using the property nodes you would use a reference to the control. Each control will have a unique reference. However using the same label makes it a little more confusing to know which reference you are working with but you can have property nodoes for both. The reference is the true unique identifier for controls and indicators.

[CoastalMaineBird]

I started wondering what happened when you had two controls of the same name and you tried to set their values through VI server

It is a bug for YOU to label two controls with the same label, IF you're going to turn around and address them by LABEL.

If that was the ONLY way to address them, then it would indeed be a bug in LabVIEW.

But it's not.

Two controls have two terminals - LV will NEVER confuse them.

You can create PROPERTY NODES attached to them, LV will NEVER confuse them.

You can create detached PROPERTY NODES and supply your own references to them, it's up to YOU to keep them straight.

It's actually useful in some circumstances; if you have a cluster on the left with a control called NSAMPLES, and a cluster on the right with a control called NSAMPLES, then you have two controls called NSAMPLES.  Maybe you want to disable them both until the gizmotron is up to speed; you can attach a property node to each field and disable them both.

[Alexander_Sobolev]

It is a bug, but of the developer, not LabVIEW.

Element has a unique identifier within application - reference. Labels are for programmers, they can use whatever they want. If they get messed - it is their fault, they did it on purpose. During copying items LabVIEW changes names to avoid duplicating the only way to get "bad" label - manually.

It does not make sense for me if LabVIEW will check for duplicate labels and pop up annoying windows. If you see a duplicate or an empty label - it is just a sign of the bad programming style, it is more usefull.

[CoastalMaineBird]

it is just a sign of the bad programming style

--- Not necessarily.  The example I gave above, for instance. If they're instances of a TYPEDEF, then they're necessarily labeled the same.

[Call_Me_Vinny]

So, as stated, I completely understand that under normal circumstances this is horrible practice.  In fact, I only realized that this was even possible went a colleague pointed it out to me.

And I realize that I could be using control references instead which are the true unique identifier.

The point that I'm trying to make is that the Control Value.Set function at the very least implies that the Label can be used as a unique identifier.  If that function is going to treat the Label as a unique identifier than it should be a unique identifier.

[CoastalMaineBird]

the Control Value.Set function at the very least implies that the Label can be used as a unique identifier.

Well, as you've seen, drawing that inference is incorrect.

It is nowhere (that I've seen) stated that way.

The help for CONTROL VALUE.SET explicitly says that it "changes the value of the first object whose label matches the string you wire".

[Mark_Yedinak]

---

@Call_Me_Vinny wrote:

So, as stated, I completely understand that under normal circumstances this is horrible practice.  In fact, I only realized that this was even possible went a colleague pointed it out to me.

And I realize that I could be using control references instead which are the true unique identifier.

The point that I'm trying to make is that the Control Value.Set function at the very least implies that the Label can be used as a unique identifier.  If that function is going to treat the Label as a unique identifier than it should be a unique identifier.

---

I would disagree with that. Using the label as your only means of identification is again the programmer's issue, not LabVIEW's. There is no way LabVIEW, or any language, can prevent all bugs or bad code. The developer has to have some responsibility too.

[Todd_Lesher]

Display the captions (which may be the same), and make the labels unique.