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!
Showing results for 
Search instead for 
Did you mean: 

Control Reference Improvement

Status: New

The current implementation of Control References on the Block Diagram could be improved. This Idea was first conceived over a year ago in a discussion on Smaller Static Refs, in the comments here.



Consider the following advantages:


  1. It's generally bad style to have Ctl Refs with hidden labels. New implementation always demonstrates the label to comply with inherent self-documentation of G (just like a Local)
  2. Smaller footprint combined with better visual distinction between Ctl Refs doubly improves information density
  3. In general, the Control Class does not need to be shown at all times on the BD. Rather, it could be shown in Context Help (currently, CH is not useful when hovering over Controls Refs, but this is another topic), or determined by browsing Properties/Methods.
  4. Eliminates the undesirable ability to rename/delete a Control Ref Label such that it no longer matches the Terminal Label.
  5. Creates a better distinction between a Control Ref and a Control Class Constant (NULL Ref). The color of the Static Refs denote a "live link" with a control, while the muted tones of a Class Constant indicate no such link (NULL)
  6. Complements the new LV2010 Local Variable upgrade (see image), yet remains distinct by having a different glyph, different background colors, and no directionality arrow
In summary, a Control Reference revamp could reduce the footprint, increase readability, and prevent obfuscation that decouples the Static Control Ref from the Control.
Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Proven Zealot

Personally when I work with references like this I'm more interested in knowing exactly what TYPE of reference it is and not what it's called.  I personally like the "String", "Path" and so on becuase I know at a glance exactly what I'm dealing with (which has direct influence on what I can do with that reference as a result).


Colour change - why not but then you have a discrepancy between the terminal colour and the wire colour which might look wierd.

Knight of NI Knight of NI
Knight of NI

It seems I'm going to be the opposite of Shane on this one.


Unlike him, I don't think I look at the type of the control, because the type would usually either be coerced (e.g. by using Build Array) or it will be obvious as soon as the ref is used. The name of the control is much more useful.


I also don't like the color change in, because I think the distinction between the locals and the refs in your mockup is nowhere near clear enough.


I'm voting for this because I do feel this area could be improved, but the solution I think I would prefer is if they all kept their color, similar to the path and ref at the bottom of your mockup.

Try to take over the world!
Proven Zealot

Well the majority of reference handling for me is done in (mostly re-usable) sub-VIs so the name of the reference is pretty useless to me.


Of course I can envisage times where the name youd be useful.  Can we have both somehow without cluttering too much?


Ps the benefit for me of the TYPE as opposed to the NAMe is not when creating new code but rather when either refactoring old code or trying to deal with a customers mess of wires.

Knight of NI Knight of NI
Knight of NI

> the majority of reference handling for me is done in (mostly re-usable) sub-VIs


Yes, but Jack's idea is about a reference to a control. Such references only exist in the same VI the control is in. In a subVI, the reference would appear as a control terminal.

Try to take over the world!
Proven Zealot

Oh, OK, that's true.


I also have to agree with your poitn regarding the differences between locals and references though.  One could easily mistake one for the other (and the choice of glyphs is somewhat short of being clear in this regard).

Trusted Enthusiast

tst, yeah, I had to type point #6 to also convince myself there's enough visual distinction. How about putting "ears" on the refs?



Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Trusted Enthusiast

I just noticed something... in LV2009 and previous, the Ctl Refs are colored based on datatype, and in 2010 Ctl Refs are all the same muted colors. Can someone confirm this? Perhaps, this was so Refs would not get confused with the new LV2010 Locals?


This was a bad move. It's far more benign to confuse a Static Ctl Ref with a Local than to confuse a Static Ctl Ref with a Class Specifier Constant. As soon as you wire to a node, your mistake is evident (broken wire) with a Local, but wiring a Class Specifier Constant to a PN or IN manifests itself as a run-time bug.

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

I like last JackDunaway proposition, but agree with Intaris about the colors discrepancy. A new standard for references?

André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
Proven Zealot

> Can someone confirm this?


Here is how various items look on the diagram in LV 2010:


Trusted Enthusiast

Yes, I can confirm the Static Reference is colored based on the Control Type in LabVIEW 2009, whereas LV2010 used the muted Static Refs (the same colors as the Class Specifier Constants).




So, why did it change in LV2010? AQ, can you get the inside scoop? I'm guessing someone figured it now looked too much like the LV2010 Local Variables. But as I said before, confusing a Static Ref with a Class Specifier constant is much more detrimental than confusing it with a local.


So really, this Idea has become "Change Static Refs to be more like the legacy Static Refs, except embed the Label rather than the Class, and maybe put ears on it"


Waiting to hear back....

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW