LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

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!

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
9 Comments
Active Participant

Yes, great design!

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.

Member

You are the man!

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

 

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Member
If control name is too long, it takes too much space. I think it is not an good idea,
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."


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
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.
Proven Zealot

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