Option to force unique labels on controls and indicators

[silmaril]

Every control or indicator in LV has got a label and a caption.

If I understand the purpose of those two items correctly, the label is used as some kind of unique and (at runtime) unchangeable identifier, while the caption is a text to display on the front panel, change at runtime etc.

I don't understand, why it's possible to have several controls with identical labels.

I agree that it would be kind of hard to force labels to suddenly be unique (it might even break some code), so I would like to have an option to do this.

In the VI settings there should be the option "force unique labels for controls & indicators".

The default for new VIs should be set in a global option  "force unique labels for controls & indicators for new VIs".

For existing VIs this option should be set to false, so we don't break any existing code.

When this setting is changed from false to true, LV should check if there are any duplicate labels on the diagramm.

If there are any duplicate labels, LV should show a message to inform the user that hitting the OK button now will change some of his labels.

If there aren't any duplicates, the change should be applied without any further notice.

You ask yourself, why I don't like duplicate labels?

They lead to VIs that are very hard to debug if you are using property/invoke nodes.

They lead to even more problems if you are using property/invoke nodes to access controls using their labels.

It just doesn't feel right to have two elements with the same name. That's a bit like having two variables with the same name but different content in other programming languages.

[JackDunaway]

Could someone explain why LabVIEW allows duplicate (or empty) labels for controls/indicators? Although I fully agree with this Idea (and should add a corollary, no empty labels should be allowed), I have withheld Kudos because I'm assuming there's a good reason for the current behavior. (And if this Idea is implemented, I would not want it to be an environment option, I would expect it to be the standard.)

So, could someone explain why?

[smercurio_fc]

We had a discussion about this a few years back.

[JackDunaway]

I searched and found that thread just after posting my message, but that thread was inconclusive on the "why" question. Yes, the thread addressed a few exploits, and the consensus seems that the solution is to simply throw a compiler warning for the VI (or leave it in VI Analyzer), but no one has still addressed the question: why are we allowed to have multiple FP objects have the same label or a zero-length label?? Basically, what is it that is so cool that we can do with non-unique labels that outweighs the potential negative ramifications of having two FP objects with the same name?

Also, your link is busted, try this one: Why does LabVIEW allow me to have two controls with the same name? 

Message Edited by JackDunaway on 04-26-2010 11:02 PM

[silmaril]

Thanks for the link to this discussion! It contains some very interesting aspects of this topic.

One of them is that duplicate labels should at least throw a compiler warning (which wouldn't break any legacy code, but still gives you a way to look for this kind of issues).

I even get a warning for unwired front panel terminals. Don't tell me this is worse than duplicate labels!

Another very good idea is that we shouldn't be allowed to use empty labels.

I'd still like to have the option as described above, but now I'd like to extend it:

* Empty lables should not be considered unique (which means they are not allowed).

* If this preference is not set, duplicate labels should still generate a warning.

[CrystalTech]

Anothe tid bit of information... "Pascal" did not allow variables to have the same name.  This was a very solid but restrictive form of code.  So, when "C" was created (written with Pascal), the designers decided to allow varibles with the same name (possibly to minimize restrictions).  Labview was designed as a graphical form of "C"; thus the same features.  Personnally I have found the feature not to be a problem, but I have the benefit of being the only one writing the code.  I may think differently if there were a team by my side.  I do agree "empty labels" should not be allowed.

[silmaril]

Yes, C allows redefinition of variable names, but not within the same scope (and if you redefine a variable name in C, you lose access to the original variable until the end of the current block).

Since LV controls are not really the same thing as C variables, there seems to be no 100%-way to match the idea of variable scopes to LV. Allowing duplicate labels on the same panel is definitively not the way to do this.

I, too, favour the idea that the same label should be allowed on the panel of different VIs, but not on the same panel.

I'd also like to state that G is not a graphical form of C. Data flow is (thankfully) very different from sequential statemens. I don't want to start a flame war over the question which one is better. In fact I use and like both languages very much. Everytime I use one of them I am missing certain things from the other (and vice versa). 🙂

[kdmcmullan]

One of my larger suites requires a pre-existing in-house tool to be able to script the front panel.

Traditionally, this tool can address variables in a program using a symbol table. LabVIEW has no publically accessible symbol table, so I address the front panel objects programatically by their labels.

It would be spectacularly useful if there were some built-in protection against mutiple controls with the same label. I have written a tool which highlights any such instances, but it would be better if this were automatic.