LabVIEW Idea Exchange

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

Fixed Size For Array Control

Status: New

It would be helpful to have an array control property that fixed the number of elements in the array control to the specified size.  This would allow the developer to programmatically set the array control dimensions such that the user is unable to add new elements to the array.  This is specifically necessary when the number of elements in the array control may vary and may also be too large to display all of the elements.  If the scrollbar(s) are visible, then the user will always be able to add a new element add the bottom by editing the available empty element value.  This is undesireable if the developer wants to prevent the addition of new elements by the user.

   

Please see the discussion forum post below for the details of the issue and current workaround.

http://forums.ni.com/t5/LabVIEW/initialize-array-control-dimension/m-p/1221930#M520867

 

 

Thanks
Dan

9 Comments
altenbach
Knight of NI

(I was just about to propose this, but then I saw this idea).

 

I agree that this would be a very important feature. In order to simplify the UI and associated code, I often use arrays of controls in the front panel.

 

For smallish fixed size arrays, this is simple: We can hide the index display and scrollbar and resize the container to the exact number of elements. If the arrays are taller than the front panel, we need to add a scrollbar. Unfortunately, the scrollbar overshoots the current array by one element, making it easy to grow the array by one, and making it difficult to enforce a fixed size that can only be resized programmatically.

 

One workaround is discussed here, requiring either an Xcontrol or extra code.

 

 

 

All we need is a new property e.g. named "allow resize" for the array, default is true to duplicate the current behavior. It should work for arrays of any dimension. If set to false, the following changes are applied at run time (they are ignored in edit mode):

 

 

  • Clicking on an element outside the current range at runtime (greyed element!) has no effect.
  • Scrolling to the bottom of the array stops at the last element and not "last element +1"

 

 

 

 

 

rex1030
Active Participant

DBerry and Altenbach are right. Please implement this immediately.

 

*Insert rant about how annoying it is doing coding gymnastics because settings are not more consistent between controls here*

---------------------------------
[will work for kudos]
CoastalMaineBird
Trusted Enthusiast

I agree with this!  Have just fought to do a customized array with a slider. Can't seems to make an actual scrollbar work.

 

I would vote for the "allow Resize" property.

 

I agree with the scrollbar limit being last element, not last element+1.

 

Not sure if we should just ignore the clicking in a non-existent element.  If it looks like a numeric field, I ought to be able to click it.

 

But yet it could happen: if you set NUM ROWS to 10 and only have 8 elements in the array, there has to be something there.

 

Maybe blank space?

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

jusaca
Member

Is there no new development? I think it is quite important to have fixed size arrays, not only for frontpanel elements but in general.

ErikL68
Member

I hope this hasn't been abandoned - it really would be valuable especially if you're trying to deal with memory limitations.  I can only assume that a fixed-size array would make for more efficient memory usage when the fixed-size is truly appropriate, such as storing a MAC or IP address. And as Altenbach points out, making it an option disabled by default (or, "Unlimited" enabled by default) would remove any concerns with legacy code.

BertMcMahan
Active Participant

Adding another "bump" to it even though I kudo'd it already. This would be a very useful feature when allowing users to edit a list of, say, DAQ channels (like the name or scale factor) where the array has an arbitrary size dictated by hardware that may not be known at edit time. There are obviously workarounds, but this seems like something that should be "baked in" if it was possible. Keeping my fingers crossed!

wiebe@CARYA
Knight of NI

And the bump worked. This is one too. +1, this is a pain to work around.

Lucither
Active Participant

I assumed that this would be an option on the RT platform to help with memory management like it is implemented with the FPGA. Seems odd that it isn't standard to me. 

------------------------------------------------------------------------------------------------------
"Everything should be made as simple as possible but no simpler"
resono-mp3
Member

This would be useful when passing an array from RT to FPGA using read-write node.