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

[X.]

Not sure whether this is an intended feature, but that could potentially cause some headache... Luckily you can still find the right control by right-clicking the Property Node (except in this case of course).

Tested in LV 2011.

[RavensFan]

I'd say this is expected.  The label of the property node is a label for only that particular object on the block diagram.  It is just defined by default as the name of the control it references.  It's possible you would want to change that label to be a bit more descriptive without actually changing the name of the control it is linked to.

[GerdW]

Hi X,

I also opt for "expected" as Raven explained.

But be warned: IMHO renaming property nodes yields in a more likely crash of the VI (while editing). It's just my experience made with LV8.5, LV2009, LV2010...

[altenbach]

Yes, allowing us to randomly change the label of property nodes can lead to confusion and unreadable code and I don't like it.

Here is an idea that tries to address this. Feel free to vote for it. 😄

[X.]

All acceptable answers, but that's not what NI seems to have designed this for.

Proof:

Now, if I right click on the property node and use "Link to" and choose the String control, here is what I get:

Notice that the label as changed to that of the associated control.

Interestingly too, the property is grayed out, and since I can't use Ravens Fan's trick of Ctrl-Running (the VI is broken):

I'd say we have a CAR right there...

[Ben]

I can confirm that when a property node is re-linked toa incompatable datat type (was numeric now string) the value property becomes invalid. I see this in my GUI controllers when I ctrl-cpoy a prop node and wire a ref from adifferent type in.

I don't know if that is a bug or intended.

I only seem to see it on the value property but then again, it one (or only) property shared by different data types that changes when linking to a new type.

Ben

[X.]

@Ben: It makes sense in the situation that you describe, but notice that the PN is not connected in my example. Why should that break the VI? I'd say that's sloppy condition testing... I mean I could tolerate me doing that, but NI? Maybe I am missing something deep, but I think what I have done is a legitimate move.

Notice that if I click on the PN and browse down to the "Value" property, the PN gets its colors back. But I should not have to waste that time.

PS: That is actually not the point of my original post. It was just to illustrate that in the mind of NI's developers, the label of a PN is supposed to be identical to that of its control. I'd vote for that (and suggest insead of all the ideas posted under Altenbach's post, to add a caption for PN).

[RavensFan]

I think you might have found a bug, not for the label changing, but for the Link To aspect.

Last night I was playing with the labels and used a numeric and a boolean as controls.  (First two different types of controls on the front panel palette.)  Changed the name of the property node.  Linked to the boolean, the property node label changed to Boolean, and everything worked.  Certainly didn't have a broken run arrow.  I figured the Link To action goes and modifies the property node label as part of its process.  And I would expect that because the property node (as identified by its label) is no long implicitly referenced to its original control.  If the label did not change accordingly, things would get very confusing.

I see you are doing almost exactly the same thing as I did, but using a numeric and string instead of a numeric and boolean.  And it breaks the run arrow.  So the bug has something to do with the string datatype.  Now if you go and repick the Value property node on that again, the it is fixed and the Run arrow becomes good again.  (And going from a string back to numeric breaks it also.)  Boolean to String and String to Boolean also breaks.  But if the property node is Visible, changing among Numeric, Boolean, and String does not seem to break.  So the issue seems to be centered on the String datatype and the Value property node.

In my experimentation, I came across another tidbit.  There is some inherent linking between the control label and the property node label that survives the actual creation process of the property node.  If you change the control label, (or terminal label on the BD), the property node label updates accordingly.  If you edit the property node label to be something else, then edit the control or terminal label, the property node label does not update, that inherent link is broken, and it stays what you had manually typed in.  (I don't know how things would behave if you do all this by way of scripting to change labels of objects on the BD.)  I would say that this is desired and expected behavior, as if I wanted the property node label to say something else (which I don't think I ever actually have), I'd want that change to stick, I wouldn't want LabVIEW changing the PN label everytime I changed the control label.

I'm still wondering, what exactly are you doing, how are you managing to be the person that stumbles across all these oddities that other people have not come across?  Not all of them are bugs as some of the issues you bring up are your own interpretation of how things should be vs. others vs. the LabVIEW designers.  But you do find more than your fair share of actual bugs that do need to be fixed.  I think this numeric property node being relinked to a string issue should be considered a bug and investigated.

EDIT:  I see while taking a long time to write my message and experiment some more in LabVIEW, you've discovered that repicking the String Value Property fixes the node.

---

@X. wrote:

PS: That is actually not the point of my original post. It was just to illustrate that in the mind of NI's developers, the label of a PN is supposed to be identical to that of its control. I'd vote for that (and suggest insead of all the ideas posted under Altenbach's post, to add a caption for PN).

---

I think that idea makes a lot of sense.

[Ben]

---

@Ravens Fan wrote:

I think you might have found a bug, not for the label changing, but for the Link To aspect.

 ...

I'm still wondering, what exactly are you doing, how are you managing to be the person that stumbles across all these oddities that other people have not come across?  Not all of them are bugs as some of the issues you bring up are your own interpretation of how things should be vs. others vs. the LabVIEW designers.  But you do find more than your fair share of actual bugs that do need to be fixed.  I think this numeric property node being relinked to a string issue should be considered a bug and investigated.

...

---

I've pondered the same thing and have come accept that X has the gift of a critical eye.

I nominate X to be a PAID Beta Tester.

Ben

[Darin.K]

You are being warned:  Possible hijack in progress, feel free to stop reading now and move on.

Implicit or Linked PNs are syntactic sugar, saves you creating and wiring a reference to a normal property node.  It is possible bad form to change the label, but I like to anyway.  Why?  I sometimes like to hide the names of the properties and use the label to describe what I am doing.  Saves space in many cases, especially when you get a few verbose names.  Used sparingly it is not too bad.

Warmup for craziness:  It is possibly a bad idea to change the PN label, at least debatable.  Now why in the heck can you change the label for a reference?  I'd like to know a good use case for that one.

Craziness:  While I really like using implicit property nodes, I kind of dislike having to use them.  They completely break data flow (even references should be thought of as data in my view).  Creating references and using normal PNs also has a break in the flow.  The reference is still separate from terminal (ie. value).  Here comes the craziness, from a visualizing data flow perspective, I would like to have a BD terminal consist of a value input/output and a reference output.  That wire can flow to PNs and I can follow wires instead of matching labels.  My brain is wired to follow the flow from control to indicator.  Somehow we have this G-world where values flow through wires (unless you are one of those people...), and references just float through the ether.

I have tried this a little.  I'll put the control reference right below the terminal.  It is not bad, especially with wire labels these days, my biggest complaint by far is that normal PNs take up so much room displaying the Class.  If there was a way to not show the class name, but keep the property/method names that would help keep the size in check (should be same as implicit PN then).  When I can trace back to the source, I do not need the class name.

Now back to your regularly scheduled programming.