LabVIEW Idea Exchange

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. 

The Desktop Execution Trace Toolkit (DETT) collects hundreds to thousands of data points that indicate memory allocations, queue references, events, and more.  The data is always available and often is overwhelming.  The only way to make sense of data quickly is to create custom probes that create highlights in the data, however, that is only after you know which VI is worth probing further.

The idea:

Feed all the data normally collected by the DETT about a LabVIEW project directly into Nigel so that it can provide human-friendly suggestions explaining:

Level 1

How often a VI allocates memory in a repeated fashion

The time jitter between different events

VI's that could be good candidates for refactoring

Level 2

Improvements to the code within that VI based on best practices for optimal compiler operations.

This is based off a discussion at GDevCon #6 on September 10th, 2025.

It's hard to believe that this is the first post to request something like this (pun intended), but I couldn't find it after a few queries.

The base idea would be that both the static and dynamic connectors used to connect the methods to the owning class shall be defaulting to the owner class, a.k.a. this object in text based languages. The main problem is the use case for refactoring. When moving around methods the class controls and indicators have to be replaced every time. It doesn't matter if I'm moving methods between classes or to interfaces it is the same pain: replace the connectors (with QuickDrop), then change the names to class names, then update the icon, finally move the VI to the new location.

I know that this could and maybe is already solved with scripting, but I think the development environment shall grant the option to change the control and indicator to this object that will always default to the owning class, without manual updates. Even the labels could be This in and This out, and replaced in real time with the actual class implementation on the block diagram of the calling VIs.

The proposed solution would also get rid of the error telling about the dynamic dispatch controls shall reference the owning class, since it would happen automatically.

The zooming feature in LabVIEW was way past due, particularly with the advent of 4k displays (and the rapid degradation of my sight!), but was implemented very poorly.   As mentioned in other idea exchanges, the font size handling is awful, and regardless does not address the ancient-looking pixelated block diagram interface.   Also the zoom resolution has too many steps for how drastically the view contorts with each step. 

The entire system should be overhauled as vector-based so it looks crisp at any zoom level and zooms smoothly between zoom levels.   The shining light example of smooth-zooming is Miro which handles text sizes and detail-loading even better than Google Maps. 

I am really looking forward to not squinting at pixels, and LabVIEW is literally the last offender I work with.

I couldn't find this explicitly mentioned here, but it seems related to:

Block diagram references should be 16 pixels tall (currently 19 pixels) - NI Community

Same Height of Unbundle by Name / Terminal / Local Variable - NI Community 

Although making changes like this could hurt legacy code, earlier implementation is preferable. Local variables are already the same size as bundles and property nodes, but constants are not. My suggestion is to increase the size of bundle/unbundle elements by one pixel and decrease the size of constants by two pixels by reducing their border thickness. Since numerics require a type indicator, a 1 px border wouldn't compromise recognition. Numeric constant type visualization - NI Community