LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Hopefully low hanging fruit? I'm constantly checking the error list when working in a VI that's part of a broken class hierarchy to see if the VI itself has errors or if it's just due to a hierarchy error or dependency error. I often repeatedly check it to confirm if the VI I'm currently working in has the errors and could save a bunch of time if something was different about the broken run arrow and I only had to glance at it to confirm I can move elsewhere in my development as expected, or continue to the error list to see what's really broken.

View All (3)

LabVIEW for ARM processors

The following code will essentially do what I want, but I want this to be natively incorporated into the IDE as an option.

90%+ of the VIs that I write have a front panel that doesn't get shown to the end user, and yet, whenever you open a VI what does it show you? The front panel. I think the default behavior of opening a VI should be to show the block diagram ONLY. This would have several advantages for the developer:

Fewer windows to manage - Even if you minimize the front panel, you can still accidentally restore the FP when you Alt-Tab or click in the taskbar which brings me to...
Less clutter in the taskbar - Once you open more than a couple VIs, navigating to the block diagram of the VI you want in the taskbar becomes very unwieldy.
You could more easily get to the BD of VIs running in a subpanel.
It would be possible to get to the BD of a VI that has a custom run-time menu where Ctrl-E is disabled.

Ideally this would be an option in the Tools --> Options dialog (that I would always turn on).

This idea is similar to one posted almost 15 years ago, but I don't consider this a duplicate because this takes things a step further by not opening the FP at all.

Problem: Viewing and/or hiding labels on the block diagram is an important part of programming in LabVIEW. In general I display the labels of subVIs, native functions (e.g. TCP Read or Obtain Queue), constants, and structures such as Case Structures, For Loops, While Loops. But sometimes, for a variety of reasons, I choose to hide labels.

Currently toggling the visibility of labels can be done either by right-clicking and navigating to Visible Items >> Label or by using the AddLabels QuickDrop shortcut (Ctrl+Space + Ctrl+Q to make labels visible, Ctrl+Space + Ctrl+Shift+Q to make them invisible).

Both options are slow for such a common, repetitive, and necessary action. While I admire the intention of the QuickDrop shortcut, and do use it from time to time, it unfortunately cannot achieve the virtually-instant response that should be associated with this action.

Solution: Label visibility should be toggled by pressing a single key, for example key "L" for label. For example, if the TCP Read primitive was dropped with its label being hidden, then selecting the primitive and hitting "L" would make its label visible. No need to navigate with the mouse. No need to load QuickDrop (which can take more than one or two seconds, especially when working in large projects).

Notes

While key "L" is proposed above, I would be happy with any other key being chosen as the trigger of this action.
I would be happy with a key combination, such as "Ctrl + L" or similar being chosen.
The action should work for groups of selected objects, just like the two current ways of toggling label visibility work on groups.
The idea above refers strictly to objects on the Block Diagram, as that is where I need this feature most. It would be a bonus if the new functionality would apply to objects on the Front Panel too.
This idea sits in the "improve developer productivity" category. I want my IDE to enable me to be as productive as possible. Every second matters. In fact, even tenths of a second matter.

View All (3)

If we want a ring of a string type we can use a combo box and if undefined items are not to be allowed it *could* behave as a regular ring (integer type) with no text editing/input, but that is not an option in LabVIEW now. Having such an option would allow us the keep the behaviour of multiple ring controls identical (and hence more intuitive to the users) although their types behind the scene for programmatic convenience are different.

If you want to keep the ring as a string (to not have to deal with it indirectly though the ring/enum string array property, which would be the current workaround...) you are currently forced to accept that the this ring will behave differently than other ring controls or enums:

In Microsoft applications the suggested feature is available by setting the style of the combo box to DropDropDownList.

Hi,

When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:

Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:

To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):

The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.

Cheers,

Steen

View All (2)

View All (3)

Recent improvements to editing string constants on the block diagram—such as enabling Ctrl+A to select all text—have been very helpful. When testing parsers, I frequently work with large string constants, and smooth navigation becomes important.

Currently, scrolling inside a string constant always moves by a single line, regardless of the operating system’s configured “number of lines to scroll per mouse wheel notch.”

Please update LabVIEW so that scrolling within a string constant honors the OS-level scroll-wheel configuration. This would make navigating large constants more consistent with user expectations and system-wide behavior.

Auto-expanding nodes

Say you have new errors you want to merge into an existing structure. You have to expand the merge error, then bring the new error to the merge. Here is what I'm proposing.

Start wiring the new error, then click on the merge error node.

LabVIEW expands and connects the error wire

This would also be nice for any expandable node like build array, concatenate strings

BA and Cat.png

Bonus points idea, but might cause more polarization so don't let the entire idea hinge on this. Clicking on an existing unbroken wire can insert the node.

The existing UI behavior just wires a new source into an existing wire, which really only breaks the wire. I'm not sure the above behavior would take capabilities away from the user. For build array to work this way, it would have to detect if the singleton was the same type as the array wire you were clicking on. This is a bit more iffy in my mind.

View All (1)

We need a “modal when called” behavior where the VI is NOT modal when the VI is not currently running (being called). Otherwise, accidentally opening the VI during development while the main VI is running will make it so you can’t interact with any other front panels, block diagrams, or any other LabVIEW windows; and you’re stuck — you have to kill LabVIEW from task manager or cmd.exe (taskkill /f /im LabVIEW.exe)

My work-around is to add this little snippet of code that uses a Floating behavior in development and a Modal behavior in a built application (EXE).

right-click -> Find In Project

I was almost certain this idea already existed, but I couldn't find it. If it does exist, please cross-link and disable this idea.

There are a coupe of functions which could really benefit from backwards propagation of data types. By this, I mean the ability to change a functions input datatypes based on a wired output.

Some functions already do this (like Variant to Data). However, that implementation has its flaws (as far as I can tell, the backwards propagation only works if wired to an indicator terminal).

Functions like Select, Obtain Queue, and Create User Event would benefit greatly from this (as well as many others).

Essentially, what I would like is a Type Specialization Structure that works backwards.

To implement this using today's technology, I guess we could create express VIs which have scripting function calls whenever the outputs are wired??? But that's janky and not practical for everyday development.

Simple example of Select

Here's a previous idea I posted, for this post, I'm proposing a generalized version of what I suggested there.

Sidenote: here's a plugin I created to make working with Select easier.

The new debug window in LabVIEW 2025 Q3 automatically expands arrays to show all elements across multiple lines. While this full view can be helpful, it often becomes disruptive during debugging.

I have attached a video that shows a side-by-side comparison. The left side is LabVIEW 2025 Q3, and the right side is LabVIEW 2024 Q3.

As you can see, when an array contains many elements, the new multi-line display consumes a large amount of vertical space on the block diagram. This pushes other probes and data displays down, causing their positions to shift and making it difficult to monitor them. There are many cases where I only need to see that the array contains data, not every single element, and I would prefer the more compact, single-line view.

I propose adding a feature to allow users to select the display mode for arrays in the debug window. It would be ideal to have a toggle or option to switch between the new multi-line view and the classic single-line view, similar to how it worked in LabVIEW 2024 Q3 and older versions.

This would provide the flexibility to choose the most appropriate view for the situation, greatly improving the debugging workflow and the visibility of other data on the diagram.

View All (1)

View All (2)

Currently, new sublasses require the user to find the correct parent class in the class tree. In larger projects, this can be really painfull.

I suggest two simple things to improve this very common task:

1. Make the class tree searchable: Put a filter string input above where you can filter the tree by name

2. Add a "Create New Sub-Class from this Class" Item to the context menu in project explorer. This could simpy open the class tree with the matching class already selected. Something like this would also be great for interfaces.

View All (2)

I often use the "Find All Instances" option from the right-click menu when clicking on a VI's icon to find all callers of that VI. However, it regularly comes up with fewer hits than the "Find Callers" option. In this case, it came up with 0 hits:

However, if I navigate to the VI in my project (ctrl+shift+e) and then right-click on it and select "Find -> Callers" it will actually find the callers:

I've never understood this discrepancy, and I see it regularly. Perhaps this is more a bug than a feature request -- but I do feel that if these callers are consistently findable from through one of these mechanisms, they should be consistently findable through both.

Note: in the case above, if I do open the VI (after finding in using "Find Callers"), it will then be found if I "Find All Instances...". But if I close the VI, it's no longer found using "Find All Instances".

LabVIEW Idea Exchange

Show a different broken arrow when the VI doesn't have errors itself.

Remove redundant path information in Project Explorer

LabVIEW for ARM processors

Make the default behavior of opening a VI open ONLY the block diagram

Pressing the "L" key should toggle label visibility

Add dropdownlist style option to LabVIEW combo boxes

Indicate that array constant contains more elements than currently visible

Introducing "Quick Classes" (an all-graphical way to define classes and anonymous functions all in one)

Respect OS “Lines Scrolled” Setting When Scrolling String Constants

Auto-expanding nodes

Give me a “modal when called” Front Panel / Window behavior or I will Kill LabVIEW (taskkill /f /im LabVIEW.exe)

Allow file renaming to record changes to capitalization only in Windows

right-click -> Find In Project

Generalize backwards propagation technology - Backwards Type Specialization Structure?!

Add an Option to Display Arrays in a Single Line in the Debug Window

Align objects should not align increment/decrement buttons

Make creating subclasses less painfull

Toggle selection of entire array with the spacebar

"Find All Instances" of a VI should be just as capable as "Find -> Callers"

Dark mode for LabVIEW IDE