Control Reference Improvement

[JackDunaway]

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.

[Intaris]

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.

[tst]

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.

[Intaris]

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.

[tst]

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

[Intaris]

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

[JackDunaway]

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

[JackDunaway]

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.

[Manzolli]

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

[AristosQueue (NI)]

> Can someone confirm this?

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

[JackDunaway]

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