Embedded labels for property and invoke nodes

[altenbach]

We've had a few recent discussions relating to labels of block diagram objects. I don't think the following came up yet, but I think it's one area where improvements are really needed.

If we create a property node or invoke node, it has a label indentical to the linked object. However, this label can be changed to anything we want, possibly leading to code that is very confusing! For example if we had two terminals labeled A and B, we could label the property node linked to A with "B" and vice versa, completely obfuscating the code!

(The beginner could also incorrectly assume that changing the label is the correct way to change the association to a different terminal)

These nodes should really have the label of the linked terminal hardwired to the corresponding terminal name, because anything else simply would not make a lot of sense.

My graphic is not as nice as Jack's here, but I think the idea is clear. It would certainly need a few tweaks from the art department. 😉

We might need an option to hide the label. Oversized labels should be truncated for display, only showing the full text when hovering.

[GregSands]

Yes, I had the same thought when looking at the other thread, and created this image as a possibility:

It also suggests that a Reference could follow the same format by enclosing the Terminal glyph with a Ref-colored box.

[altenbach]

Good idea. Maybe there should also be a little glyph to distinguish property nodes from invoke nodes.

(maybe a wrench and a thunderbolt, for example ;))

Currently, they look the same to the untrained eye and a programmer might be unsuccessfully scrolling through properties while he actually wants to duplicate a method from some code picture.

(The graphical differences currently only shows when nodes are not linked to a control/indicator)

[JackDunaway]

Totally with you on this one! Took the liberty of creating a few more Property/Invoke Node upgrade suggestions.

@GregS: I went through several iterations with the Property Node banner, the first several of which had the lighter shading that matched the datatype. I ended up going with the cream coloring that matches the unlinked nodes, but I don't know if I like my version as well as what you showed above. As for the datatype glyph, I like how it looks on the PN, but in my suggestions I reserved it only for the terminals, simply for distinction.

Also, one problem with dropping it in the ref wrapper is the vertical raster is now larger than the other nodes, meaning horizontal wires coming out of stacked refs would require bends. Keeping a consistent vertical raster across terminals/locals/refs/PN stacks is important to me.

I wish we had a better format for iterating all these ideas!

[tst]

Another option would be to simply lock the label and not allow the user to change it or to have it change the label on the control as well.

I voted for this idea, as well as for Jack's, but one thing which implicitly linked PNs and INs are missing today is the class. You can't find it either in the node or in the context help.

 

One option for dealing with this is having the label as it is today and showing the class in the header, which will make it more consistent with explicitly linked nodes.

Another option is showing the class in the context help.

[tst]

> I wish we had a better format for iterating all these ideas!

I suggest you create a new group in the communities called idea brainstorm or something similar (I actually had the name IdeaStorm in my head for a few seconds before I realized why it might be a problem). Maybe "lightbulb"?

In this group people can create discussions or documents for ideas they have and which they consider not to be fully worked out. Once some sort of consensus has been reached, you can post the idea with a link to the document.

Since the communities finally work (sort of), people can subscribe to the group and receive updates. This will actually not work too well with documents, because whenever an edit is made to a document, you get an alert with the whole document, so maybe sticking to discussions is better. You can diff the document if you go into the site, but it's not the smoothest system around.

[Ray.R]

..... I like the idea....

I still have to tthink about Christian's initial post and those suggested by other, and including Jack's "sister thread" (http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Block-Diagram-Terminals-Improvement/idi-p/1223522).

My only concern,  but not opposition, is the size of the terminal when dealing with long names.  And how are the terminals going to affect code written in older (previous) versions. 

[X.]

I am linking this to this thread.

My own suggestion is as tst, to lock the label to that of the control and possibly offer a caption for PN, so that people may customize them, if needed.