I got some code from a coworker that I'm building into an EXE. There are a lot of references to user.lib (like 60 classes) and the folder structure that my coworker gave me makes some of the classes in user.lib too long and causes the exe to fail building.
I moved the stuff from user.lib to a root folder on my C drive and now I have to manually update every class because they aren't in user.lib. Its pretty time consuming and I think just saying "Look in this directory for the missing files" would help tremendously for larger projects that need to get moved around.
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:
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.
The QuickDrop action above would result in three numeric constants being dropped, as seen below.
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.
Notes
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".
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.
VS Code displays the number of selected characters.
LabVIEW should display the number of selected items in the Project Explorer.
LabVIEW should also display the number of selected items on the block diagram and the front panel.
Notes
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 Module.vi 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).
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
Step 2 - current behaviour: double-clicking creates a terminal. This is useful. Holding modifier keys down (Ctrl, Alt, Shift) does not alter the behaviour.
Step 2 - desired behaviour: Holding modifier key + double-click creates Unbundle By Name node
Notes
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.
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).
Solution:
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.
Nice-to-haves
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.
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.
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!
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.
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).
At present, build paths in build specs are stored as absolute paths, unless the path happens to be in the same folder as the project. Relative paths that are a level or more up from the project folder are not supported. Modifying the XML directly does not support relative paths either.
When working on multi-developer projects, where source control root folders may be different, this can be a serious annoyance. One of the better workarounds at the moment is to build to a non-desired relative path (within the project folder) and then to run a post-build action to move the generated files to the desired location.
But it shouldn't have to be this way -- relative paths should just work. (They are supported elsewhere in projects, such as with dependencies.)
(Note: this is the follow-up to a post on the LabVIEW forum about the same issue.)
Suppose that in the scenario seen below we would like to merge the error out terminal of VI 2.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.
Notes
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.
Suppose a front panel contains the three elements seen below, with the first one being selected.
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.
If Tab was pressed again, it would cycle to the next element in the tabbing order, as seen below. And so on.
Notes
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.
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.
Example
Screenshot 1: A GUI element (control or indicator) with a custom, non-default label and value (contents) font style.
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.
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".
Notes
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").
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 C.vi from Library 1.lvlib to Library 2.lvlib
Screenshot 3: Typically, I would now press Ctrl + E to switch to the Files view, right-click the file, and select "Move on Disk...".
Notes
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.
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:
