LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
JackDunaway

Further Property and Invoke Node Improvements

Status: New

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

 

Property Node Concepts

22360i1B976CE68F1194B3

 

Scripting and Invoke Node Concepts

22364iA43FCE953263A787
  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!

9 Comments
GregSands
Active Participant

Yes, great design!

RavensFan
Knight of NI

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
Member

You are the man!

RandyP
Member

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.)

-Randy
-=--=-=-=-=-=-=-
Nothing like a good dose of LabVIEW to cure what ails ya'.
JackDunaway
Trusted Enthusiast

 


@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
Member
If control name is too long, it takes too much space. I think it is not an good idea,
altenbach
Knight of NI

> 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
Active Participant

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?


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
AristosQueue (NI)
NI Employee (retired)

> 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.