LabVIEW Idea Exchange

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

Add an input for Array to Cluster function

 

I feel this should have been done long ago considering that its a simple change that would add a small level of convenience to this standard function.

Add an input for 'Cluster Size' in the Array to Cluster function to avoid right clicking and then selecting the Size for the Cluster in a separate window!

7 Comments
AristosQueue (NI)
NI Employee (retired)

That cannot be done without introducing new language features into LV. LabVIEW does not have the concept of a terminal that is "constant input only". Because the value wired to that terminal would actually change the data type of the wire coming out, it would have to be wired with a constant or be broken.

 

We could modify the node itself to have a textbox region inside of itself, along the lines of the Expression node, but that would be a significant amount of work, albeit much less than creating the idea of "constant input only" terminals.

 

Speaking purely for myself and not the rest of NI evaluating this idea: Both of these approaches are a large amount of work for what seems to me to be a minor annoyance. I think it would take a lot of user kudos to make either approach worth doing.

tst
Knight of NI Knight of NI
Knight of NI

Also, this has already been suggested - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Change-CLUSTER-SIZE-to-a-Wired-Input/idi-p/991527


___________________
Try to take over the world!
Darin.K
Trusted Enthusiast

In that brief moment while we have visibility before being lost to duplicate-land:

 

(1) Why 9?  I come close to losing sleep over this one.  Consider the following exchange I have had a few times on the forum:

OP: Blah, blah, blah, 9, blah, blah, blah

Me: Did you configure the Array to cluster node?

OP: ##@%$%$, I didn't know you could do this.

 

(2) I'd prefer this node be deprecated in favor of an improved Coerce-To-Type function.  With icon views of clusters now, this does not have to be super ugly.  Type Def explosions may still wreak havoc.

 

(3) Does the current node have to work as dropped?  Perhaps there is a way to have it broken until the programmer enters a value.  Put a red 'X' on it until a new value is entered.

 

(4) It could be "Expressified", ie. pop up the dialaog when dropped.  Might make sense, although that happens to be a feature I dislike about Express VIs. At least in this case there is no alternative to enter that value, the few ExVIs I use accept wired values.

 

(5) I do not know what counts as 'significant work', but to me all things are simple when someone else is doing it.  Smiley Wink   Adding a text box to the node could be easily done with an XNode, the most time consuming part for me would be drawing the image.  Tool regions and text boxes are pretty simple to implement and the generated code is quite simple.

 

Responses to 2-5 are completely optional, but once again Why Nine?

AristosQueue (NI)
NI Employee (retired)

> Why Nine?

 

In all honesty: why not? 13 years ago it was a good number (Perforce logs only go back to 1998).

tst
Knight of NI Knight of NI
Knight of NI

> Why 9?

 

Because it's the one number guaranteed never to be useful, so it annoys everyone equally. 😉


___________________
Try to take over the world!
Darin.K
Trusted Enthusiast

In all honesty: why not?

 

My only argument against it is that it creates a "lurking" bug in the code.  It may not bite often, but a bit of a pain when it does. 

 

When I ask for zero elements it insists on giving me one. I was hoping it would throw some error and zero would be a good replacement.

 

It could be that bundling 8 elements is a 64 px node and one more is just too much.  Since it predates Tony Romo then I suppose it is not the jersey number of some developer's favorite Cowboys player.  Perhaps a dartboard was involved.

srdfrn
NI Employee (retired)
Status changed to: Duplicate