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!
cancel
Showing results for 
Search instead for 
Did you mean: 

Size to Contents feature for BD constants.

Block diagram string constants have a useful feature "Size to text" which is accessible through the standard right click menu.  One way in which this is useful is to ensure that information in an array of constants is not hidden: Right click on an element of a string-constant array and select "Size to text" and it will expand to show the full length of all the strings it contains.

 

What's needed is an equivalent for numerics (including rings and enums).  When dropped singly, these constants expand and shrink around their contents.  But if you drop a numeric constant on an array constant, it takes the size of the numeric and can only be expanded manually.  If you then enter a constant that is longer, only the first part will be shown, and there is no indication that the values are truncated.  (see image)

 

I think that arrays of numeric constants should resize to show everything entered, automatically.

 

16985i3AA6C5F1591D73F6

-Barrett
CLD
11 Comments
Active Participant

I don't like this too.

My solution is use Enumerators in Cluster (with AutoSize -> Arrange Vertically) and Cluster to Array.

Now LV compile constant before run that this conversion is not time consummation when VI is running

 

                                                         17415iC8DE6AC643417464

Trusted Enthusiast

@JCC (SK) wrote:

Now LV compile constant before run that this conversion is not time consummation when VI is running


I think you misunderstand this Idea if you think it's a run-time performance improvement. This Idea focuses solely on the usability of the IDE. (Also, just for future reference, consummation has a different connotation in English than what you intended Smiley Wink )

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Knight of NI

The lack of this feature has been annoying me for years!

 

Kudos for posting the idea! Smiley Happy

______________________________________________________________________
Active Participant
JackDunaway wrote:
@JCC (SK) wrote:

Now LV compile constant before run that this conversion is not time consummation when VI is running


I think you misunderstand this Idea if you think it's a run-time performance improvement. This Idea focuses solely on the usability of the IDE. (Also, just for future reference, consummation has a different connotation in English than what you intended :smileywink: )


I thing you misunderstand my Comment. There is not note about a run-time performance improvement.
Member

You could also make it so that double clicking on the "re-size" mouse grab point does this function as well. Kind of like in an excel spreadsheet when you double click the sizing tool on a column or row.

Member

Bravo!  Often in the Queued state machines you put enums in an array to "feed" the Queue.  If you update the Typedef of the enums, voila, all your arrays containing this typedef collapse to a certain minimum width, and in larger applications it takes a long time to manually re-size them all.  Óur current event structure has about 100 cases, and so there is a lot of work to  clean this up.  Pure waste of time.

 

Carsten Thomsen

 

 

Active Participant

Carsten,

 

I played around with that for a second and it looks like when you edit the typedef (normal *or* strict) such that it needs updating, the array recalculates its size based on the size of its default element, so you could make sure the default item isnt short...  I bet you could script the resizing pretty easily, too. (search for every instance of an array constant whose element type is X and resize the constant to width N)

 

That makes me think that an excellent way to implement this would be just like cluster autosizing:  with "autosize to contents" checked, the array constant would check to make sure it wasn't obscuring any part of any of the array elements.

-Barrett
CLD
Member

Re suggested autosizing behavior: Yes, I've been annoyed in the past by the current resizing behavior after I change an enum typedef and my array constants get munged as shown above. For a long time I had thought it was just me, but knowledgeable people said they thought it was just endemic behavior....

 

Re blawson's reply to Carsten's comment: Good workaround--but NI really should resize constants the suggested way.

Example Gatekeeper
Status changed to: In Beta
 
DNatt, LV R&D
Example Gatekeeper
Status changed to: Completed

Available in LabVIEW 2015 and later

DNatt, LV R&D