Changing the Property Node label does not update the Terminal/Control label?

[X.]

@ Darin. K: In your second step, the Value PN did not change from Write to Read on its own, correct? I only use LV 2011 at this point (which somehow messed up my LV 2010 and LV 2009 installations, so I rarely go back and check things there).

[Darin.K]

That would have been even better, I did that by dropping a new one to show the sequence of events.  Actually, the PN fixed itself in the process of copy/paste to show the Delete String Ref step.

[Jeff-P]

Hello everyone,

Thank you for bringing this to our attention! I was able to recreate this in LabVIEW 2011 SP1 and it certainly seems like a bug so I will investigate some more to see if this has already been filed as a CAR and if not then I will file it and post back with the CAR number.

Regards, 

[Darin.K]

Just to be clear, the bug you are reporting is the behavior of the Value property when switching references, correct?  Not the behavior of changing Property Node Labels (debatable as feature vs bug), or of Reference Labels (not debatable, clear bug IMO at the very least undesirable behavior).

[Jeff-P]

I have filed this as CAR 339553. The specific issue I recreated was that when you have a property node (both explicit and implicit) for the Value property if you change the type to or from a String you get unexpected behaviour - it does not adjust the data type, even though it does successfully adapt the data type between other types (for example boolean and numeric). This is an inconsistency so it was filed as a CAR. In addition I specifically noted that this allowed the behaviour of being able to wire a value of the wrong data type into the string data type Value property as explained in Post 17.

As for the issue with the labels, I played around with it a little bit and the behaviour seems to be as intended. While I agree that the ability to change the labels on property nodes can lead to inconsistencies and difficult to read code I do not think it is a bug. To clarify your last point, when you refer to the Reference Labels behaviour are you talking about how you can change the label on a reference and it does not update the label on the control that it references? I am able to recreate that behaviour but I am not sure it is a bug although I agree it seems undesireable and could lead to extremely confusing code (ie if you change the label of a reference from one of your controls to have the name of another one of your controls).

[X.]

Has Murphy's law been repelled in the state of TX, maybe?

[Darin.K]

Thanks. To be clear, yes I think it is a mistake (maybe or maybe not a bug) that you can edit the label of a control reference constant. I don't think the labels should be tied together so you can change either one, I simply think the label of the constant should not be editable.

[Jeff-P]

Hi,

So I have looked into the behaviour of the reference labels and this is the intended behaviour and not a bug. If changing the behaviour is something that the community feels strongly about, the best approach is to create an idea on the idea exchange, similar to the one Altenbach suggested in post 4 of this thread. Thanks to everyone for their input!

Regards,

[X.]

Jeff, I have already added a comment to that effect to Altenbach's suggestion (which I don't really support, but I obviously agree that the issue that it raises and attempts to solve is important). A label/caption distinction solves the issue

Thanks again for looking into the issue. I think you probably meant to say that the current behavior was designed to allow changing the label of a property node but the UNINTENDED consequences of this were OVERLOOKED 🙂

[Jeff-P]

Yes, the current behavior is consistent with other similar labels on the block diagram (they are editable), however because Control References and Linked Property Nodes do not explicitly indicate which control they are linked to in any way other than the label, this can lead to issues with labels being changed and code becoming unreadable. 

Regards