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. 

[Sam_Sharp]

I actually got caught out by this today - I thought that changing the label of the reference would update the label of the control/indicator...nope. I think that would actually be my preferred solution - that the reference label is linked to the control/indicator label and vice-versa?

[Intaris]

I'm fine with just disallowing the edit.

[wiebe@CARYA]

Changing the reference\property node\method label and than changing the control\indicator would have made sense if it would have been like that from the beginning.

Coming from how it is now, it would be confusing to me. Especially when switching versions.

Just disabling would work, but in combination with fixing the label if it's off. If we convert old code, and a label is off, we'd either need to change it back or it should be fixed automatically.

[Darren]

I considered proposing that changing the reference/implicit node label would change the label of the control, but I'm concerned about accidental label changes, i.e. times when the user thinks he's just changing that node's label, not realizing it changes the control's label. It feels to me that the control label text should be defined in a single place on the diagram, and that's at the terminal. Local variables don't let you change the control label, so I'd prefer if references and implicit nodes behaved the same way.

[AristosQueue (NI)]

I didn't even know these were editable. I would've thought, if they were editable, that it would change which control was linked. I definitely wouldn't expect this to be a way to change the label of the control.

Given the various interpretations of what it means to change the labels, I think I agree that just preventing the edit and locking the label to always be the referenced control is the right solution.

[Darren]

---

@Aristos Queue wrote:

I agree that just preventing the edit and locking the label to always be the referenced control is the right solution.

---

If you and I agree on something right out the gate, I think that's a sign that we should definitely do that thing. 😉

[wiebe@CARYA]

What's going to happen with labels that where previously (old LV versions) changed?

I'd say change them to the original label. Is there another option?

The only situation where changing the labels makes (a tiny bit of) sense, is scripting. The script would be able to distinguish nodes by the label... Definitely a corner case.

[AristosQueue (NI)]

> What's going to happen with labels that where previously (old LV versions) changed?

Don't know. Options would have to be discussed if this idea goes forward.

Besides "change them to make them match", I can brainstorm that we might leave them unchanged and just show a load warning that they don't match expected name. That would avoid most scripting breaks and still let users know that they had a problem in their code... they would need to re-drop the node to correct the issue since editing wouldn't be an option anymore (or change the label of the control, which would then auto-update the linked node). We could draw the problem labels in red to warn others that the labels are out of date?

There would still be a scripting break for anyone who was writing to the label as part of scripting (that would return an error), but that will occur in any of these scenarios.

[wiebe@CARYA]

I think the number of people doing this exact trick with scripting is neglectable? Or just collateral damage. Sounds like a corner of a tiny case inside a corner case to me.

[AristosQueue (NI)]

I once had a "this might affect one customer" change... only one customer ever reported a problem... a $2-million account that went into panic mode. I've been responsible for a couple other, smaller-but-still-cringe-worthy incidents with breaking changes. I try not to be cavalier about "just one customer" these days. Sometimes it is still worth doing the change, but I hesitate, and if there's another way, I generally lobby for it. I have some of the worst "allergies" on the whole LV team in that respect.