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: 

Allow "To More Specific Class" to operate on arrays

So this isn't a huge deal, but it would be nice if we could put an array of classes into To More Specific Class to convert all of them to the more specific class. There are handfuls of functions that work well on both arrays and single elements (the Math functions, Close Reference, etc).


Error Out would need to become an array as well. I can't think of anything at the moment that this might break, or any poor patterns it might enable, it would just save a For loop here and there. I made a quick example vim just to illustrate, but it'd be nice if it was part of LabVIEW core.



Active Participant

Array TSC.png


Dangit, I can't edit my original post to attach the .vim. Let's see if I can have a .vim in a snippet Smiley Happy

Proven Zealot

I floated making this change once... worked up a bit of a prototype. The users I talked to became divided about what the node should do in the fail case. When only a subset of the input objects fail the type check, what should the node output?

a) an empty array and a single error cluster that says some objects failed

b) a non-empty array that contains only the objects that succeeded the downcast and a single error cluster that says some objects failed (with one person arguing it should be a warning).

c) a non-empty array that contains the same number of elements as the original array, with default objects in the positions that failed and a single error cluster that says some failed.

d) same as (c) but with an array of error clusters, mixing "no error" and "error"

e) same as (c) but with an array of error clusters of only the failures

f) same as (b) but with an array of error clusters, mixing "no error" and "error"


I'm sure there's some other permutation.


Eventually, I concluded that the pattern variations were so myriad that it was better to leave the node alone and let people code the solution they needed in each case. With the introduction of VIMs, this becomes even easier.


I'm not saying LabVIEW shouldn't do this... I'm just saying I don't know what the right answer looks like.

Active Participant

Fair enough. The vim I made up does d), as it feels to me the most "complete". With all of the other ones, there's no way to know which specific element failed the conversion check without doing it manually in a For loop, which defeats the purpose of the exercise. If you need to know if Any failed, not just Which one failed, you can throw a Merge Errors onto the end of it. Filtering the array to only get the ones that passed would be fairly simple as well with an additional For loop autoindexing the array with an autoindexed/conditional output.


Basically I feel like if you went with d), you could implement the rest down the line. You coudn't do that with the other options.


Anyways, it's a small thing and I already have a .vim that does what I need, so it's no big deal either way. I just like thinking/learning about this kind of thing. Thanks for the info about the history of this request.

Proven Zealot

> there's no way to know which specific element failed

> the conversion check without doing it manually in a For loop


Apparently, for a whole lot of people, this is a "who cares" scenario... it's useful info while debugging, but not for the execution of the program. And generating an array of errors is arguably a waste of memory. And there's the question of behavior in the "all succeeded" case... do you generate an array of all "no error" or an empty array? If an empty array, it means you have to check for that special case downstream.


I thought I knew which one would be the best option; I no longer do. It'll be interesting to hear other comments. If there is a consensus, it would be easy enough to ship a VIM these days with LV.

Active Participant

My biggest use case for this would be type-testing a bunch of objects so I can then dynamic dispatch on the "good" ones in a sub-tree of the inheritance hierarchy*. For that use case I would want (i) only the objects returned that succeeded in downcasting, and (ii) a single error/warning cluster which I would probably just ignore anyway. That's a definite vote for (b).


If I wanted 1-for-1 output objects and/or an array of error clusters then I would just wrap the prim in a FOR loop...


*It always feels like the "proper" thing to do would be to add the appropriate abstract methods to the base class, but that is often undesirable when the class hierarchy is deep. You just end up with a glut of abstract methods at base level that are not relevant to most of the other child classes.

Chris Virgona