LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Neil.Pate

property nodes should accept arrays for the reference

Status: Declined

Any idea that has received less than 9 kudos within 9 years after posting will be automatically declined.

Idea Subject really describes it.

 

Property nodes should allow arrays of references on the input so that the same property (i.e. disabled) can be applied to multiple controls without needing a for loop.

 

Errors could be handled much the same way as compound property nodes are now, ie with the option to ignore errors within the node. I imagine most errors would occur during development time anyway.

9 Comments
JackDunaway
Trusted Enthusiast

Autoindexing the array of refs in a For loop cuts it for me, and I think is more intuitive than wiring an array of ref's into the PN.

 

Think about it... PN's or Invoke Nodes with outputs would alternatively have either scalar or array outputs, depending on whether the input was a scalar or array. It's more intuitive to me to always keep the inputs and outputs as scalars, then put it in a For loop if you want to autoindex the inputs or outputs.

 

Neil.Pate
Active Participant

I don't know, it would be pretty intuitive to me if a thick wired array of control references was wired into the property node.

 

I agree it gets a bit messy with outputs, I was thinking more of the simple case where a scalar is used as an input. Although for outputs I think it should be an array out if an array of references was passed in.

Knight of NI
I agree that it's more intuitive to have it kept scalar. While an argument can be made that so many functions in LabVIEW are polymorphic and can act on arrays as well as scalars, so why not the property/invoke nodes, I think that property/invoke nodes should be left out of this. Part of why I say this probably has to do with having programmed in text-based languages where properties/methods act on a class. An array of classes is not inherently a class, and therefore cannot have property or methods used on it. While you can have a class that is an array of something, the reverse is not true. In other words, an array is not automatically a class, but a class be defined as being an array of something.
tst
Knight of NI Knight of NI
Knight of NI
I find that this would actually make sense and probably wouldn't have any syntax issues (it should return an array of refs and either an array of errors or a single error based on a right click selection), but I'm not sure it's worth it.

___________________
Try to take over the world!
JICHFI
Member
I had the same idea about enqueue element. It should be handled to enqueue an array of the same types of the queue type.
Ray.R
Knight of NI

I have to think about this one...  I tend to agree with JackD on this one..  I do understand the benefit of setting a property or an invoke method to a whole bunch of controls using a single wire (array). 

 

... Like I said... I have to think about this one..  For now, I'm sitting on the fence.

JackDunaway
Trusted Enthusiast

Also, consider LabVIEW does not cleanly handle jagged (ragged) arrays without clustering the elements. This would add a level of complexity when adding the next dimension to a property node that already outputs an array (Index Vals, Annotation List, Cursor List, Chart History...)

SteenSchmidt
Trusted Enthusiast

I think this would be a valuable addition, and it quite thoroughly follows the trend with several requests for other primitives to handle array input (Close Reference etc.).

 

The property node should just omit the (very rare) selections with array parameters when you wire an array of refnums to it. Just like the event structure does, when you combine slightly dissimilar events into a single event case. Stuff that can't be handled with the current configuration simply disappears from the list.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 9 kudos within 9 years after posting will be automatically declined.