Further Property and Invoke Node Improvements

[JackDunaway]

I'm totally on board with Embedding Labels for Property and Invoke Nodes! Here are some additional improvements to those nodes:

Property Node Concepts

Scripting and Invoke Node Concepts

1. Most importantly, the banner now more closely resembles a Static Control Reference.
2. The directionality arrows are a pixel width's larger - more distinct, and matching the size of the new LV2010 Local Variables.
3. The node banner is the same height as the unlinked property node.
4. Property Nodes and Invoke Nodes are distinguished by the Property Wrench and the Action Arrow glyph.
5. Scripting properties/methods are now more distinct. Currently, the small node banner inherits a few pixels of light blue distinction if any one property on the property stack IsAScriptingProperty. Proposed, shading will be applied on a per-property basis, allowing better visual distinction and a more coherent choice for what to shade.

Discussions/suggestions/insults/questions encouraged in comments section!

[GregSands]

Yes, great design!

[RavensFan]

I like how the blue for scripting based nodes is only on the particular property rather than highlighting the top info bar.

[A-T-R]

You are the man!

[RandyP]

Nice. I definitely would re-iterate the comment that long labels should be truncated (and tip-strip on hover for the whole thing). I'm sure there are plenty of legacy VIs out there that have some lengthy control labels where the labels on the BD property node labels were truncated for space reasons. We definitely don't want property and invoke nodes the size of a football field due to their labels.

(This all is setting aside the style issue that labels probably shouldn't be that long.)

[JackDunaway]

---

@Ravens Fan wrote:

I like how the blue for scripting based nodes is only on the particular property rather than highlighting the top info bar.

---

Thanks! It works great for the properties, but it's not so straightforward for the invoke nodes: some invoke nodes have the method name in the "top slot" (see Start Drag above), while others do not show the method name, or hijack a form of the method name as an output (see Replace above). In this scenario, it's not so straightforward what should be highlighted light blue (especially when optional inputs have a slight grey tint). Perhaps, a new Idea should be created to always show the method name in the top slot? Maybe, an additional glyph could be added when IsScripting? is true?

---

@RandyP wrote:

 I definitely would re-iterate the comment that long labels should be truncated (and tip-strip on hover for the whole thing)

---

I'm ambivalent on this one. The point of having the embedded label is to disallow improper documentation, so it's counterintuitive to be able to configure the node such that the name is obscured. Tip-strip is great when you're in the environment, but does not help you in a screenshot or a printed BD. I'm going to lean toward saying this functionality should be allowed but stylistically discouraged. My favorite implementation is the resize handles combined with an ellipsis.

[stupidboy1121]

If control name is too long, it takes too much space. I think it is not an good idea,

[altenbach]

> If control name is too long, it takes too much space. I think it is not an good idea,

As explained here, this is not a problem and has an easy solution:

"Oversized labels should be truncated for display, only showing the full text when hovering."

[LabBEAN]

Like this, Jack.

Most primitives don't prompt the developer to wire the error cluster by tagging the terminals with a "?!" glyph.  In the original node, there is room so the glyph may be helpful to some (if they even know what "?!" means).  For me, retaining the "?!" in the new node would create noise when scanning a diagram for nodes with wrenches versus arrows.

So, can we let the "?!" artifact go the way of the double-wide boolean constant?

[AristosQueue (NI)]

> So, can we let the "?!" artifact go the way of the double-wide boolean constant?

Actually, the ?! is more likely to become more common in the future, since if every error terminal was marked that way, it would be easier to scan a diagram and check that you have wired all the error terminals.