LabVIEW Idea Exchange

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

The Deployment Progress window should display the amount of time that has elapsed since the deployment started. The screenshot below shows a possible implementation.

Notes

• Please ignore the arrow that points at "Deployment completed with errors". I had to reuse this screenshot which was originally created to serve a different topic.
• This idea is similar to the following idea: The Build status window should display elapsed time. I created two separate ideas for the purpose of keeping each idea small and self-contained.

Feature or bug ?
Actually you can build polymorphic VIs with VIs with different pattern signature (the connectors block) and that's very nice !

But even if the Select type option let you choose every instance, only instances with the same signature can be selected others are ignored.
We should be able to select every VIs defined in the Polymorphic VI.

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.

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.