From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Allow the Select comparison function to accept an array as its S Select input. This would allow the result of an array comparison to be followed by the Select function and if that array were then wired to one of the Select T or F, would allow each array element to then be replaced individually based on the separate boolean result. One of the Select input (T/F) would be allowed to be a scalar so the array element could be replaced by that one value if desired. This capability would provide an alternative to performing this operation with a For Loop and take up less diagram space.
You're mixing two ideas and redefining the operation of the Select function. Is the Select supposed to select between two data sources, or replace? The Select function was never intended to be used for replacement of anything, and I don't think it should.
It wouldn't need a Comparison Mode. In fact, a Comparison Mode would be meaningless. It just needs to be polymorphic on the inputs. If the middle terminal is an array, all terminals must be arrays. If the middle terminal is a scalar, it has the behavior it has today.
As a member of R&D, I have no problem with this idea. If it gets enough kudos, it is totally doable.
As a LV user, I don't like it. Putting a For Loop around a node is not a substantial burden and I generally prefer the readability of the code without these sorts of overloads *when multiple terminals get involved*. So I'm in favor of things like Close Reference becoming polymorphic to accept an array of refnums; and I'd like for Property Nodes to accept an array of refnums, but I wouldn't want the properties themselves to then become an array. There are too many times when things have gotten confused about how many elements are in the two arrays. At least the Property Node has error terminals to report a mismatch. The Select node does not.
It wouldn't need a Comparison Mode. In fact, a Comparison Mode would be meaningless. It just needs to be polymorphic on the inputs. If the middle terminal is an array, all terminals must be arrays. If the middle terminal is a scalar, it has the behavior it has today.
As a LV user, I don't like it. Putting a For Loop around a node is not a substantial burden and I generally prefer the readability of the code without these sorts of overloads *when multiple terminals get involved*.
So if the True and False terminals were forced to be scalers, you would be fine with the idea? This is the situation I have most found myself in when wanting this feature.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5