LabVIEW Idea Exchange

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

Color properties should default to colorbox data

Status: Completed

Available in LabVIEW 2019 and later. Creating a control, indicator, or constant off any color terminal will create a color box instead of a U32 numeric.

(As already hinted here, I think this deserves a seperate idea).

 

Property nodes have many items that accept color data (cursor color, plot color, bg color, etc). When right-clicking these and "create constant|control|indicator", we get a generic U32 type. Instead, we want a colorbox! Even more complex color structures, e.g. (colors[4] of a boolean) should have colorboxes as the innermost elements.

 

In all instances I have ever used these properties, I ended up replacing the U32 with colorboxes for code readability and simplicity.

 

Idea: when creating an input or output (constant, control, indicator) on any color property, we should get a colorbox (control, constant, indicator) instead of a plain U32 numeric. 

 

color.pngcolor.better.png

14 Comments
Knight of NI
Interesting idea, though I wonder about its feasibility. How does one distinguish a "regular" U32 from a U32 that's a color value? Perhaps a new datatype is required, or would that be too radical? (Sort of like how in .NET you have a Color class.)
altenbach
Knight of NI

Well, it could search the property name for the string "color", for example. 😄

 

I wonder how many exceptions this would need? How about a lookup list of all color properties?

AristosQueue (NI)
NI Employee (retired)

> How does one distinguish a "regular" U32 from a U32 that's a color value?

 

Alternatively, since R&D has to tag every property with things such as "Must post to root loop" or "Depricated" or "Not valid when VI is running", we could have one more flag that says "is a color"... That would save on having to change types all over.

altenbach
Knight of NI

Just an additional note: A similar thing happens for clusters.

 

For example: I have a cluster (typedef), where one element is a colorbox. If I do a "bundle by name" and e.g. "create constant|control" on the color element input, I get a plain U32 numeric instead of a color box. This should also be handled the same way, if possible, so that we get a colorbox constant|control, etc.

vt92
Active Participant
I think it is a great suggestion. 
Message Edited by vt92 on 03-19-2010 02:31 PM
>

"There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal
JÞB
Knight of NI

Another great idea!  the dup reciently posted pointed me back here.  Ideally, these color constants shuld have tip-strips that display the RGB values on hover in edit mode


"Should be" isn't "Is" -Jay
altenbach
Knight of NI

(A duplicate of this idea has recently been posted. Here is a link for reference)

Darren
Proven Zealot

How about if, when you right click a terminal or a wire, if that terminal/wire is a U32, or is a data type that only contains clusters/arrays containing U32, then the right-click > Create pull-right would contain:

 

Constant

Control

Indicator

Color Box > Constant

                 > Control

                 > Indicator

 

In other words, a 'Color Box' pull-right allowing to you create color box elements where the U32 numerics would otherwise have been created. Would that feature sufficiently solve this use case?

wiebe@CARYA
Knight of NI

@Darren,

How would that work for U32's in clusters (or arrays with clusters)?

 

I thing no alternative\workaround will be faster then QD, "box", CTRL+P.

Darren
Proven Zealot

The right-click menu would appear for a U32, or any nested type that only contains U32s (like clusters of U32s, or arrays of clusters of U32s). 

 

I agree that Quick Drop Replace will adequately solve this use case, but the right-click menu item is more discoverable for users who don't use Quick Drop or haven't incorporated Quick Drop Replace into their workflow.