LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

A very common task when operating with 2D pictures are mouse down/move events where we are interested which pixel was just clicked. While there is an event data node for the clicked coordinates these are relative to the front panel and translating them into image pixel coordinates is a chore and requires ~~jumping through flaming hoops~~ tweaks. (i.e. label yes/no? zoom factor? etc.)

However, there is a "Mouse" property for 2D images that has all the information directly in pixel coordinates and mouse button states. Currently, we need to read that property inside the mouse event to easily get the information we always (always!!!) want in such an event!

It would be cleaner if mouse events on pictures would output these mouse properties directly as an additional event data node.

Two clear advantages:

Cleaner code for those who know how to work with this property.
Stop sending newbies on a snipe hunt trying to figure out how to translate the current "coords" event data node into something useful for the intended task.

Here is an example where this idea would have helped

Here's a picture for the graphical thinkers!

Thanks for voting!

What is a strictly-typed reference?

A strictly-typed reference is a kind of reference whose type descriptor contains an inner, user-specified data type.

For example, a queue is a strictly-typed reference because it contains the data type for its elements, specified when creating the queue.

Here is a non-exhaustive list of such reference types:

- Queue

- Notifier

- User event

- DVR

- Datalog file reference

- Strictly-typed control refnum

- Strictly-typed VI refnum

- Shared variable

- Network stream (reader/writer)

- RT FIFO

- FPGA IO / register / memory / FIFO / handshake

- ...

Idea:

Add a new primitive that would output the inner data type of any strictly-typed reference.

Here is a design example of the primitive, which could be named "Get Contained Data Type of Strictly-Typed Reference":

It would work for all the strictly-typed references mentioned above.

Motivations:

The implementation of malleable VIs is sometimes limited (or made complicated) by the fact that we miss some basic "type operators", such as getting the contained data type of a strictly-typed reference. While this missing function could be implemented using some tricks for most strictly-typed reference types, it is for example impossible for user events (See this thread for more details).

Typical application:

A malleable VI that takes a user event (for its type) and outputs a newly created refnum with the same contained data type:

This simple code is currently impossible in the general case due to the nature of user events.

Remarks:

1. The output terminal of this primitive will have to be named exactly as the contained data type, which is crucial for user events.

2. The output would have the LabVIEW default value for the data type (False for booleans, 0 for numerics, "" for strings, ...).

3. The primitive could be placed in a dedicated "Malleable VI Tools" palette.

4. In case the FPGA-specific implementation creates a dependency to the FPGA module, we could have a separate primitive just for FPGA (and also for RT if required).

What do you think?

Regards,

Raphaël.

View All (8)

I work with PPLs quite a bit...and sometimes...I just want to rename them.

Libraries that depend on the renamed PPL will then be broken, as expected. Example here:

It would be awesome if I could simply go in, right-click on the missing dependency, and replace it with the newly named one. But...for whatever reason...this option is disabled. Instead, I find myself having to go in and manually replace each individual broken PPL call (VIs, typedefs, etc.). This is unnecessarily time consuming and error prone.

We know that LabVIEW has some magic that it uses for automatic error handling. What if LabVIEW could use such sorcery to enrich the error string flowing on the wire, with information about the originating source of the error -- specifically the VI Reference and GObject UID of the node where the error was introduced. Then a "fancy error dialog of the future" (TM) could utilize those UIDs to navigate directly to the node and highlight it (a visual effect to show which node it is). This behavior could be added to the Simple Error Handler and General Error Handler VIs, and maybe ever there could be a "LabVIEW Gems" vi.lib utility that can extract the VI Reference and GObject UID for use in other, 3rd party tools.

View All (3)

Especially when I use setting windows I normally transfer the actual settings from a setting-cluster or from global variables to multiple local variables and display the current settings in the front panel. After the user edited the settings of course the settings need to be transferred again to global variables or in a setting-cluster. So if multiple global or local variables are used, each variable need to be changed from read to write 1 by 1 by right click and selecting the action from the menu.

So I suggest to implement a function to change it at the same time for all marked variables, similar to property nodes.

The suggested procedure would be:

Mark variables with the mouse by holding "Shift" on the keyboard or drawing a frame
Right click to context menue
Change all to read / write

The feature would be consistent, because it is for example possible to create local variables of multiple controls at once with a similar procedure. (I just don't get in mind why the order is always upside down when I do this)

View All (3)

Property node for push button LED color

I want to be able to programmatically change the color of the LEDs on push buttons.

The colors[4] property will change the color of the housing, but not the LED itself.

This push button is one of the controls that is both a control and an indicator rolled into one.

In my particular case, I want to represent a third state. I have a valve that can be open, closed, or in transit.

There are two actuation states of open and close, but three indicator states.

I think making it a property I can control is a powerful solution. Not only will it solve my use case, but I can have all different colors of Booleans without needing to use Customize Control and the Control Editor to modify the colors.

Extra credit request: Can we make just the LED blink? Right now, the blinking property blinks the entire control, but wouldn't it be cool if just the LED blinked? This is what those same two controls look like when blinking:

Maybe it's a new property just for LEDs that's separate from "Blinking". I'd be okay with that if you want to preserve current behavior.

Here are some related Idea Exchange posts related to a tri-state Boolean. They're not quite what I want, but I thought I'd link to them for reference:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Tri-State-Boolean/idi-p/1139952

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Special-LED-control-with-three-states-Default-ON-OFF/idi-p/991307

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.

View All (5)

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.

View All (4)

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".

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.

View All (2)

When you're looking at the front panel of non-editable VIs, such as VIs in PPLs, many options aren't available. Some of these are still applicable, and would be really useful.

Example 1: If I want to go look at a class definition, normally I could right-click on the class in a front panel and then choose "Show Class Library". However, it isn't available if the VI is locked. My (less-than-ideal) workaround is to "Copy Data", drop the class on a new block diagram, and then I have access to all the normal menu options.

Example 2: The connector pane isn't visible. I often want to look at what is wired where on the connector pane, or to check if inputs are dynamic, but this info isn't visible.

Problem: Currently, the native nodes and VIs that can be used for error manipulation are located in the Dialog & User Interface palette. While manipulating errors can mean generating dialogues, and can influence the User Interface/User Experience, error manipulation is a broader and stand-alone topic.

Solution: Nodes and VIs that are relevant to error handling/error manipulation should be given their own subpalette inside the Programming palette. The new subpalette could be named "Error Handling", "Error Manipulation" or "Errors".

1 (annotated).png

2 (annotated).png

View All (3)

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)

Make Class Mutation History Optional

This topic keeps coming up randomly. A LabVIEW class keeps a mutation history so that it can load older versions of the class. But how often does this actually need to be done? I have never needed it. Many others I have talked with have never needed it. But it often causes problems as projects and histories get large. For reference: Slow Editor Performance with Large LabVIEW Projects Containing Many Classes. The history is also just added bloat to your files (lvclass and any built files that use the lvclass) for something most of us do not need and sometimes causes build errors.

My proposal is to add an option to the class properties to keep the mutation history. It can be enabled by default to keep the current behavior. But allowing me to uncheck this option and then never have to worry about clearing the history again would be well worth it.

Use Nigel to suggest commit message

View All (3)

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)

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.

View All (1)

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.

LabVIEW Idea Exchange

Mouse events on 2D pictures should have an event data node for mouse information

New primitive to get the contained data type of a strictly-typed reference

Allow "Replace" of Broken PPL Dependencies

Automagically include GObject UID in error messages when running in the editor

Option Change all to read/write for multiple local / global variables

Property node for push button LED color

Desktop Execution Trace Toolkit (DETT) insights provided by Nigel, the AI advisor

Make block diagram vector-based - for cleaner view on high res monitors, cleaner zooming

Toggle selection of entire array with the spacebar

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

Class controls and indicators shall default to "this" class

Show more data when looking at non-editable VIs

Error functions should be located in a dedicated palette named “Error Handling” (or similar)

Make creating subclasses less painfull

Make Class Mutation History Optional

Use Nigel to suggest commit message

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

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

Add dropdownlist style option to LabVIEW combo boxes

Support Python node on Linux compactRIO targets