Remove Default Behavior from Array To Cluster

[Darin.K]

Many of us at some point have wondered "Why the heck is the default number of elements for Array To Cluster equal to nine?"  No good explanation is forthcoming.  My new question is "Why should there be a default setting?".  I suggest that instead of defaulting to nine elements leading to some hidden bugs (I have at least 3 solutions involving this function), that the Array to Cluster function simply breaks the VI until a value is chosen.  Some possibilities for discussion.

1) Pop up the dialog upon dropping the node?  A bit Express-y

2) Double clicking the node should pop up the dialog?  I'd like that.

3)  A visual indication that the value has not been set? A few possibilities:

4) Make the value an editable text field along the lines of the comments here:

http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/2430/page/1#comments

If it is easy to do I say yes.  Don't even start down the dynamic adaptation road, that is not going to happen any time soon.

My main point is that this function is not used very often by most of us which means that it is not worth a major overhaul, and it is all the more unlikely that we remember all of the hidden behavior.  Therefore a simple tweak, breaking the code until a value is set makes sense.  Making it easier to set the value is a nice bonus, but secondary.

Someday a better method will come along (cluster support for Coerce To Type?) and this function can be put out to pasture, until then I would suggest just a little tweak.

[Darren]

I guess a suitable alternative to breaking the node (most certainly more work) would be your (1) and (2) selections above...on initial drop, give a dialog to configure the node, and make it easy to configure again later (via double-click).

[Wart]

I'd love to see the ability to double click.  Why hide something that must be set each time the node is dropped in a right click menu?

[Darren]

Now that I think about it more, we could solve this *really* easily by replacing the node in the palette with an Express VI, like we did with File Dialog.  In the Express VI dialog (that would come up immediately when dropped), we would provide a mechanism to force the user to specify a meaningful value (not 9) before clicking 'OK'.  And this gives us double-click for free.

This implementation is probably our best chance of getting the feature in...no changes required to the primitive, and a simple palette change (like the File Dialog) in the editor.  And for those of you who have veins popping out in your forehead right now at my mention of an Express VI, chill out  ... they can provide the ideal user experience in certain circumstances. I think this is one of them.

[Darin.K]

Replace Express VI with XNode and I will be happy.

[GregSands]

Please don't create another Express VI!  They prevent separating compiled code from the VI, so I will never use them. If this functionality is needed, I would also much rather have an XNode.

In the meantime, here's a prototype XNode I wrote for defining the size by wiring a cluster in: http://lavag.org/topic/14422-array-to-cluster/ - something like this would be my preference in any case because it allows for named cluster elements.

[AristosQueue (NI)]

> They prevent separating compiled code from the VI, so I will never use them.

They only prevent separation at the moment... future versions of LV will not have this restriction.

[Darren]

As AQ mentioned, the 'separating compiled code' issue will not be a problem in a future LabVIEW version. Also, let's assume we're not going to add any functionality (like the named cluster elements) if we do this feature.  So those things being said, please tell me why y'all would prefer an XNode solution over an Express VI solution.

[Darin.K]

I'll come clean, I was making a very subtle dig at the Express VI haters. Express VIs are essentially a framework for implementing XNodes so they are two sides of the same coin. Yet XNodes are mysterious and cool while Express VIs are evil. Call it what you want, it is all about implementation. I can say that I know that the XNode implementation is fairly easy, I have never made an Express VI so I can not say if it is any easier.

[GregSands]

> As AQ mentioned, the 'separating compiled code' issue will not be a problem in a future LabVIEW version ... please tell me why y'all would prefer an XNode solution over an Express VI solution.

Well, that's good to know!  That's my only reason to prefer XNodes over Express VIs.

[X.]

Just curious, Darin, what kind of bugs can result from using the default value of 9?

If you connect it to an indicator, it will result in a broken wire if the indicator does not have 9 elements in it. However, if the array has less or more than 9 elements, things are still fine (of course you will have zeroes or missing elements, but that's not really a bug per se).

If you connect it to an unbundle function, same thing, it will break if the unbundle has less or more than 9 elements...

If you connect it to a function or VI which accepts cluster inputs, same thing.

Am I missing something?

My point is that it appears difficult to not very quickly realize that you have to adjust the number of elements in the cluster to have things work as intended.

This being said, I kudo-ed the idea as I think the current behavior is sub-par.