LabVIEW Idea Exchange

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

Be Able to Resize Properties Dialog Boxes and Certain Contents of Specific Pages

Status: New

It would be really nice if you were able to resize properties dialog boxes for controls, indicators, constants, and other nodes on a front panel or block diagram. Sometimes the information entered in a dialog is larger than the allotted space. Fortunately, in those situations, there is usually a tip strip that shows all of the information rather than just the visible portion of the information, such as shown in the enum properties dialog box picture below. To make all information visible, it would be great if properties dialog box windows were resizable and the contents of the tab control pages automatically scaled with the size of the dialog. It would also be nice if pages containing objects with columns (e.g. multi-column listboxes, etc.) allowed the columns to be resized as depicted in the picture below. 

 

Ryan_Wright__2-1731433895037.png

2 Comments
Petru_Tarabuta
Active Participant

+1. An additional behaviour that would be useful: After a window is resized and closed, the next time that window is displayed it should use its most recent size (not its default size). In other words it should "remember" the last size. Ideally the window sizes would persist even after LabVIEW is closed and restarted.

fefepeto_kb
Member

 

 In other words it should "remember" the last size. Ideally the window sizes would persist even after LabVIEW is closed and restarted.

I would love this behavior to be saved individually for each control, but that would definitely bump up each VI that leverages enumerable types.

That might not be a big issue tough if implemented only for the shown tab for enumerable types. I consider this a nice touch because of the corner case:

I open the Edit Items for an enum with longer "Items" column. Then I open up a ring control at the same tab, which in turn has longer numeric values. In this theoretical use case 3 digits would be enough for the enum, because there are less than 100 values. On the other hand the ring would have at least 6 digits of space for the numeric "Values" since it uses mostly 5 digit long numbers, but short text.

 

Although extending this idea to save the size, position and last tab for each end every control is definitely overkill, and a lot of potential clutter that might impact the load performance of large projects in a negative way. I mean that it would be nice, but seams like a balancing act to me.