Size to Contents feature for BD constants.

[blawson]

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.

[JCC_(SK)]

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

                                                        

[JackDunaway]

---

@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 😉 )

[Ray.R]

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

Kudos for posting the idea! 🙂

[JCC_(SK)]

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  )

---

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

[JCC_(SK)]

@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  )

---

[JCC_(SK)]

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

[bzielinski]

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.

[CarstenPXI]

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

[blawson]

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.

[MartyS]

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.

[Darren]

Available in LabVIEW 2015 and later