LabVIEW Idea Exchange

Community Browser
Showing results for 
Search instead for 
Did you mean: 
Post an idea

You can currently pin LabVIEW projects, VIs, and other files to the file lists in the LabVIEW start dialog as shown in the pictures below:






It would be really nice if the Recent Projects and Recent Files menus in front panels and block diagrams automatically included the same files at the top of the menu item lists (and in the same order) as illustrated in the pictures below:




Recently LabVIEW has added the following feature: When creating a new wire, double-clicking creates a terminal. This can be an indicator or a control, depending on what was selected. If the wire was started from a data sink (a structure tunnel or a subVI or node input terminal), holding down the Ctrl key while double-clicking creates a constant. This is very useful and saves time. Kudos!


When working with cluster wires, it would be useful if an Unbundle By Name node could be created by:

1. Start creating a new cluster wire or wire branch

2. Hold down a modifier key (Ctrl, Alt, Shift, or a combination thereof) and double-click


Step 1: Start creating a cluster wire

1 (edited).png












Step 2 - current behaviour: double-clicking creates a terminal. This is useful. Holding modifier keys down (Ctrl, Alt, Shift) does not alter the behaviour.

2 (edited).png












Step 2 - desired behaviour: Holding modifier key + double-click creates Unbundle By Name node

3 (edited).png













  • Creating UBN nodes is a common, repetitive action when working with clusters. This gesture would save time.
  • The screenshots above show a cluster wire being created starting from a control terminal. The gesture should, of course, work regardless of which object the wire branch was started from (e.g. tunnel, subVI output terminal, etc).
  • Perhaps the idea can be expanded to creating Bundle By Name nodes. Perhaps one modifier key (e.g. Ctrl) would create a UBN node, while another key (e.g. Alt) would create a BBN node.

The LabVIEW Icon Editor plays a central role in creating graphical icons for VIs.

Yet, it has some quirks that would be great to address, such as fixing a few issues affecting users on Linux.


Because the Icon Editor is written in LabVIEW, many LabVIEW users could actually help fix issues and suggest improvements more directly, if the Icon Editor source code were hosted on GitHub. This would allow people to submit issues and feature requests (even in the form of Pull Requests with the fixed/improved code).

By transitioning the Icon Editor to GitHub, NI could establish a process that allows for the incorporation of community improvements into the official LabVIEW releases.  This would improve quality and allow for more and better feedback from the community.

Note that NI has historically shared the Icon Editor code with each new LabVIEW release (here in the NI’s LabVIEW discussion forums).  However, there hasn’t ever been an effective mechanism for the community to contribute back their fixes and feature suggestions.  So, hopefully this would only take incremental effort for exponential gains!

Control and indicator references are currently 19 pixels tall. They should be 16 pixels tall. References would then align better with other items which are already 16 pixels tall, such as the Bundle By Name and Unbundle By Name nodes.


1 (edited).png


















This idea is inspired by this idea and this idea.

Excel displays the number of selected cells.

1 (edited).png













VS Code displays the number of selected characters.

5 (edited).png





























LabVIEW should display the number of selected items in the Project Explorer.

2 (edited).png



























LabVIEW should also display the number of selected items on the block diagram and the front panel.

4 (edited).png


















  • In the Project Explorer the functionality would be useful to count/monitor/audit the number of VIs and CTLs in a lvclass, lvlib, or in a virtual folder of these owners, etc. It would be nice to know at a glance "oh, there are 12 public VIs in this class".
  • The block diagram count functionality can become more useful in large projects and VIs. For example, I recently edited the block diagram of a VI in a DQMH-based project. The project contains 16 DQMH modules at the moment (more to be added). I wanted to check that the VI I was editing was calling the Start public VI of each of the 16 modules (wanted to check that the VI would launch all DQMH modules). The only way to do this was to "manually" count the VIs on the block diagram. Selecting them and LabVIEW displaying "Count: 16" would have been easier.
  • In the block diagram the information displayed by LabVIEW could be more nuanced. For example, it could display the total number of items selected (subVIs, nodes, property nodes, etc), but also a breakdown based on item type: number of VIs, number of nodes, number of property nodes, etc. All these selection stats may occupy too much space for all to be displayed at once. Perhaps they could be displayed in an element that, when clicked, expands to present all the information.
  • The block diagram and front panel count functionality would enable programmers to quickly estimate the complexity of a VI. Pressing Ctrl + A on a block diagram to select all items, then looking at the selection stats would reveal the relative complexity of that VI.
  • If a whole structure is selected on the block diagram, then the count should return the count of all items contained in the diagram, not just the items displayed to the user. For example, if a case structure is selected, the number of items contained in all cases should be displayed.


In Windows File Explorer, Alt + double-click on a file or folder pops up that item's Properties page. It is equivalent to right-clicking and selecting Properties. This is a useful, time-saving keyboard shortcut/gesture.


The same keyboard shortcut/gesture should work in the Project Explorer. Executing the shortcut would pop up the Properties window of whichever item was double-clicked on.


The shortcut should work for lvclass and lvlib items, VIs, and CTLs (and possibly other item types too). For lvclass and lvlib items the Properties window would appear. For VIs and CTLs the VI Properties window would appear (equivalent to Ctrl + I).


Screenshot 1

1 (edited).png









































Screenshot 2

2 (edited).png














































In a recent version of LabVIEW the height of Unbundle By Name and Bundle By Name elements, Local Variables and Global Variables was standardised to 16 pixels. This was a welcome improvement. (I'm fairly sure that the improvement was suggested by a LabVIEW Idea. I would have liked to link to that idea here but unfortunately I can't find it right now.)


The size of Boolean constants is currently 16 pixels (width) x 14 pixels (height). This should be standardised to 16 pixels x 16 pixels. A vertical stack of Boolean constants would better align with a stack of local variables, global variables, or UBN/BBN elements. They would also align better with the default sized LabVIEW grid (16 x 16 grid).

1 (annotated).png










On project folder ... 

It would be great if in the project tree,

Just like any items that are called and not on project are in dependencies...

The other way would be for

- Update icons (grayed them out) for items in project without callers to be greyed out or have a different icon like an exclamation mark or similar...


that way it would be easier to know if an item is

dead code or not called by anyone


When cleaning or developing is common to forget which vis are no longer used or needed.

Currently the default front panel Alignment Grid Size is 12 pixels. It should be 10 pixels.


There is probably a reason why 12 pixels was selected many years ago, but is that reason still valid? Twelve pixels seems like an arbitrary number. Ten pixels would be more logical because is aligned with the decimal system.

1 (edited).png












2 (edited).png














3 (edited).png















The Project Explorer Files view already contains the useful "Move on Disk..." option. It would be useful if, when a VI or CTL is owned by a lvclass or lvlib, an option named "Move to Owner Folder" (or similar) existed. This option would move the selected file to the folder that contains the lvclass or lvlib that owns that file. This action would be equivalent to using the "Move on Disk..." option, but would save the user from navigating the (potentially large) folder structure to find the right folder. In short, it would save a few seconds and would help ensure consistency. It would also encourage the best practice of storing owned VIs and CTLs in the same folder as their owner lvlib or lvclass (actions that are easy to do are performed more often).


For example

Screenshot 1: A project that contains two libraries





















Screenshot 2: In the Items view, the mouse was used to drag from Library 1.lvlib to Library 2.lvlib

2 (edited).png




















Screenshot 3: Typically, I would now press Ctrl + E to switch to the Files view, right-click the file, and select "Move on Disk...".

3 (edited).png
































  • It would be great if the "Move to Owner Folder" menu item was also available when multiple items that are owned by the same owner are selected.
  • A related idea: It would be useful if, when using the Items view to move an item from an owner to another, LabVIEW would pop up a dialogue message similar to the following "Would you also like to move the file on disk to folder <insert here the folder path of the new owner>?". The dialogue would contain Yes and No buttons. This would save the user from having to switch to the Files view altogether.


It would be useful if a "Keep Text Only" (a.k.a. "Paste Values" or "Use Destination Style") option existed when pasting text into control and indicator labels, captions, or values.



Screenshot 1: A GUI element (control or indicator) with a custom, non-default label and value (contents) font style.

1 (edited).png







Screenshot 2: The text "Hello World" was copied (Ctrl + C) from Notepad and pasted (Ctrl + V) in the middle of the label. The newly pasted text is inserted using the default font (Application Font, 15 pt, black). There is no option to paste using the destination font style. The developer now has to waste a few seconds reconfiguring the font. The same result is obtained whenever the text is copied from an external (non-LabVIEW) application, regardless of the application (Notepad, Microsoft Word, Excel).










Screenshot 3: The same situation occurs when pasting into a string indicator.

Combined 3 and 4.png




Screenshot 4: In Microsoft Word, it is possible to select the "Keep Text Only" option when pasting text. In the screenshot below, notice how "Hello World" text from the second row obeys the destination style when it is pasted into the first row. A similar functionality exists in Microsoft Excel and is named "Paste Values".

6 (edited).png







  • The current behaviour, where the text is pasted using the default font style, can be useful in many (maybe most) situations. I am not asking for the current behaviour to be removed. But it would be useful to have the option to select between the two behaviours.
  • When the text is copied from LabVIEW, the pasted text maintains its source formatting style. This can be useful, but again, it would be useful to be able to select "Keep Text Only" (a.k.a. "Paste Values" or "Use Destination Style").


See this github repository for a more complete proposal and an example implementation that gets us closer to achieving this in LabVIEW.

Some languages like Rust and Zig have a feature called Tagged Enums (or Sum Types) that allow you to create a data type that can be one of a few different types where there is a name associated with each type. In LabVIEW, however, Enums are limited to consecutive numeric integer values -- there's no way to associate a type with each named value.


The power of combining an Enum with a data type for each value is that we could potentially use a Case Structure as a switch statement with type assertion and data conversion built in! This would allow us to create robust, type-safe code that is easier to maintain and understand.



See this github repository for a more complete proposal and an example implementation that gets us closer to achieving this in LabVIEW.

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.

Suppose that in the scenario seen below we would like to merge the error out terminal of VI back into the main error wire. This is, of course, a common programming pattern.











Currently we would need to insert a Merge Errors node into the existing wire (Pressing Ctrl + Space, typing "erg", then Ctrl + I is probably the quickest way to do this), then wire the error wire as desired. Currently creating a wire from the error out terminal and ending that wire onto the existing error wire results in broken wires, as seen below.











It would be useful to have an option that specifies that a Merge Errors node would automatically be inserted in this case. That option could be named something like "Automatically insert the Merge Errors node when suitable", and could be located in the Tools >> Options... menu alongside options such as "Place structures with Auto Grow enabled" or "Auto-insert Feedback Node in cycles".


When the "Automatically insert the Merge Errors node when suitable" option is ticked, a Merge Errors node would automatically be inserted in the scenario described earlier, as seen below. This would save the few seconds required to execute the Ctrl + Space, "erg", Ctrl + I sequence.













  • I would be happy if the default value of the "Automatically insert the Merge Errors node when suitable" option would be unticked, which would maintain the current default behaviour.
  • Even if the option would be ticked (enabled) by default, I think it would still make sense from a usability point of view. I suspect that the number of times people intentionally use this feature would be greater than the number of times that people wire error wires together by mistake and would wish for the wires to be broken.


It would be useful if QuickDrop supported a way of dropping multiple instances of the same item in one go. It is sometimes desirable to do so. For example, we may want to drop three numeric constants in one go.

1 (edited).png



























The QuickDrop action above would result in three numeric constants being dropped, as seen below.

2 (edited).png











Selecting an error wire, then executing the sequence: Ctrl+Space >> typing "rn" >> increasing the Number of Items to x3 >> Ctrl+I would result in three property nodes being inserted into the error wire, as seen below.

4 (edited).png
















  • It would be great if the multiplier could be typed as part of the QuickDrop search string. For example, typing "rn x3" or "x3 rn" would then drop or insert three property nodes. This would mean that the whole action can be done from the keyboard, which would be quicker. However, it seems difficult to implement due to the search string needing to be intelligently split into two parts.
  • Perhaps a much easier implementation that would be almost as quick would be to type "rn" >> press Tab (this would tab to the "Number of Instances" control) >> type "3".



There! I said it 😎.


The problem


Here's a simple vim that replaces ',' with '.' in a string (half the world uses ',' as decimal separator):


To support 1D arrays we have to (ouch) duplicate the code:


To support 2D arrays, we need yet another duplicate:


So, to support scalars, 1D arrays and 2D arrays, we get:


I don't advocate nD (n>2) arrays, but duplicate code is undesirable. And this is just a trivial example.


You typically run into the lack of malleable recursion when you do serialization (to\from string, (un)flattening, to\from variant) very quickly.


Recursive malleable VIs


If we could call the vim in the .vim, we wouldn't have any duplication:



So what's stopping recursive malleable VIs?


Well, there's a 'minor' issue of infinite recursion.


There are 2 relatively simple ways to deal with this.


1) Limit the nesting level and break caller if it's reached.


We don't need 9D arrays, and certainly not 256D arrays.


2) Check if the .vim prototype has been used before and break caller if it is.


Let's say the .vim "V" is called with a string 'A'. V" turns 'A' into an array, that in a for loop call 'V' again.


That would be a use case for normal VI recursion (calls, managed at runtime), but it shouldn't be possible with malleable recursion (inlined code).




At least not at first. The compiler could inline each prototype and when called repetitively, use normal recursion. But that would be next level, and maybe not even desirable.


The scalar string input is simply not a stable input for this malleable VI. It will always result in infinite recursive compiled code. So, this should break the caller.


Of course, it should be perfectly legal to have a disabled type specialization case that calls the same prototype. As long as it's not actually compiled, that's perfectly valid:


Problem: There are currently two ways of moving or transferring a VI or CTL from one lvlib or lvclass to another (or from having no owner to having an owner).

Method 1: Drag-and-Drop. Select the VI or CTL, drag to desired lvlib or lvclass, drop in desired location.

  • This works well in small to medium projects, and will probably remain the quickest and most common way of moving a item from one owner to another.
  • This does not work well in large projects, which can have dozens or hundreds of classes and libraries, sometimes deeply nested within complex virtual folder structures (for good reason). In this situation dragging the item can take a long time, especially when the destination lvlib or lvclass is "off the screen" and slowly scrolling through the project becomes necessary. This is done by hovering the mouse in just the right region in the top or bottom of the Project Explorer. This can be tedious and wastes time.

Method 2: Remove and Re-add. Select the VI or CTL, remove it from its current owner by right-click >> "Remove from Library" or by pressing Delete key, select destination lvlib or lvclass, right-click >> Add >> File... , then select the file on disk (this last step can take time in large projects with large folder structures).

  • This can be quicker than method 1 in large projects.
  • This method is technically a workaround. It does not directly transfer ownership of the item.

Note: Both methods usually now also require moving the file on disk to the new owner's folder location. This can be done using the Project Explorer Files view, but is an additional step that takes time. It's also possible to simply forget to move the file on disk (best practice is not encouraged). 



  • Right-click the VI or CTL, select Move to... option
  • A window appears. This window may use a Combo Box or a Listbox to display a list of all the lvlibs and lvclasses available in the project.
  • The user selects the desired destination owner and presses OK.
  • The item is moved to the destination library.

1 (edited).png















































  • The Move to... window may contain buttons or other mechanisms (e.g. clickable datagrid headers) that enable the user to sort the libraries and classes in the project by name in alphabetical or inverse alphabetical order, and to filter: display only lvlibs, display only classes.
  • When the selected VI or CTL is initially part of a lvlib or lvclass, that owner will be omitted from the list displayed in the Move to... window.
  • The Move to... window could contain a tickbox named "Also move on disk to new owner's folder?" or similar. When this is ticked, the item is also moved on disk to the folder of the new owner. This would remove the need to use the Files view to move the item on disk (would save time) and would help encourage a best practice (member items should be located in the same folder as their owner).
  • The Move to... option should be available when multiple items are selected. The items may initially be owned by the same owner, or may be owned by different initial owners.

This idea is inspired by the "Project Explorer "Move to Owner Folder" option in Files view" idea.

Suppose a front panel contains the three elements seen below, with the first one being selected.

1 (edited).png













In the situation above currently pressing Tab does nothing. It would be useful if, instead, pressing Tab would cycle the element selection to the next element in the tabbing order, as seen below.

2 (edited).png













If Tab was pressed again, it would cycle to the next element in the tabbing order, as seen below. And so on.

3 (edited).png














  • This idea would speed up development by enabling us to cycle through element selection without using the mouse.
  • When used in conjunction with the F2 idea, this would enable us to use Tab + F2 combinations to quickly cycle through elements and rename their labels and/or captions.
  • This idea could be extended to terminals on the block diagram. Suppose a terminal is selected on the block diagram, pressing tab would navigate to another terminal on the block diagram.
  • I'm aware that currently it is possible to use Tab or Shift+Tab to cycle between elements forwards or backwards when the VI is in Run Mode (Ctrl + M). While that is useful, this idea asks for more.


Many of us using graphical programming for scientific applications, where we dealing with numbers, measurements, etc.

How often we grab to Windows Calculator to compute simple equations?

What about ability to enter something like 3,75*2,8 into any constant or control (in principle everywhere where we can put numbers) and then get computation result in this place:

Screenshot 2024-03-06 09.16.22.png

In the past I've worked in desktop publishing industry and using the software called "Macromedia Freehand MX", and that was really "killer feature", which saves huge amount of time.


This is how it works:


Or for example, 5 rotated copies:


Even in Color mixer simple computations are allowed:


Everywhere where I can put some numbers, in any dialog:


So, my suggestion to have the same in every numeric control or constant.


This is what I mean:


So, it should be allowed to enter here something like "3*5" or "42+3*5" 

As MVP suggested to have the only (at least) base operations *, /, +, -, also combined as shown above, but may be "advanced" support (like fully offered by Formula String) is also not so bad, why not:


Anyway it should work everywhere, including constants on the Block Diagrams:


Also, for example, on Resize Objects Dialog:

Screenshot 2024-03-06 11.20.04.png

Or even in the Settings (in general everywhere for any numeric field across whole LabVIEW):



And also in Run-Time, of course, not only in Development Environment.


If you think that "always enabled" feature will be annoying, then I can suggest to make this optionally per Control/Constant Option:

Screenshot 2024-03-06 11.31.54.png

Or may be as global setting in the Options.

When refactoring code, I often find myself in a situation where I've broken dependencies. Maybe it's a name change, or a library path change. This is precisely when I'm most in need of the ability to just replace the missing file (be it a VI, control, class, or PPL).  Yet this is when LabVIEW decides that nope, it can't be that easy:




Instead you have to track down every instance and manually swap them out.


The request: allow us to replace missing files using the "Replace with..." option.