Disallow changing the label of control references and implicit property/invoke nodes

[Darren]

Check out this nice readable diagram:

Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.

I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either. 

[wiebe@CARYA]

I've been on the receiving end of that, although not a 2M$ account.

[donkdonk]

Very good illustration. Learned something today!

[MichaelBalzer]

Does the label behaviour in NXG cover this idea? Labels shown on references can't be edited, and local duplicate terminal labels are inherently linked to the front panel control, so changing one label changes them all.

[AristosQueue (NI)]

This idea is for LabVIEW specifically, not LabVIEW NXG.

[MichaelBalzer]

I agree, and it's a good idea. I'm just unclear where the line is when an idea for LabVIEW already exists in some form in LabVIEW NXG, and so is considered to be 'Already Implemented'. Other ideas have been closed as they are already part of LabVIEW NXG (not without reasons, of course), and this seemed like it might be one of those cases. Are there any general rules on what ideas might or might not make the LabVIEW 20xx cut? Bitmaps/vectors and string encoding seem to be common themes. Anything else?

[AristosQueue (NI)]

@MichaelBalzer Ah. I understand your question now.

We close ideas as "already in NXG" when a) we definitively are not going to do it in LabVIEW 20xx and b) we have already done it in LabVIEW NXG. This applies particularly for requests that are the reason why we chose to create LabVIEW NXG, but also for smaller features that NXG has done. An idea stays open if either platform may potentially to do it. There are clear lines for what ideas fall where, but they are dependent upon the skills and areas of expertise of those working on the LabVIEW 20xx platform, so one idea that seems fairly simple may be "yes, we could still do that in 20xx" while another equally simple becomes "no, that's NXG only." From the customer view, that may feel somewhat capricious, though Darren and I try to be clear when this is the case.

[AristosQueue (NI)]

In the case of this idea specifically, Darren suggested it already aware that NXG did it this way. That foreknowledge changes the nature of the request to one that is "yeah, it's already in NXG... can we backport that?"

[cy...]

good observation... wouldn't have caught that normally, as most user may change the label from the FP object itself. The reference label will not update itself once the reference label is manually change once, but the reference itself seems to stick. Other than misleading the reader, cannot think of any other application of this 'feature'.

On another note, possible to include a distinctive feature that can differentiate FP objects with identical labels? perhaps a ID number/glyph on the user layer of its icon? cos currently we can have 2 unique FP objects with identical labels... or just block identical labels...

[AristosQueue (NI)]

> On another note, 

Cy: Please submit that as a separate idea so this thread doesn't get derailed. 🙂

[JICR]

Learned something new today.

I found out you're correct, we can't edit subVI labels.

Although you may edit native function labels. Which is weird as well.