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).
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.
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 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:
When a subarray is created, the data is copied from the origin-array.
The LabVIEW Compiler does not recognise if the subarray data is then only read.
It would be a major improvement for memory and even CPU usage if the compiler recognised that some part of the array is only read and pass only a reference to that part of the array in the memory.
When in the front panel, most LabVIEW data types that wrap other data (such as arrays, DVRs, maps, sets, user events, etc.) allow you to directly view and modify the wrapped data. For some of these data types it is not the default behavior, but it is available if to right-click on the control and select "Show Control...".
For illustrative purposes:
In all but one of the cases above, I can see that the underlying data type is a boolean, and I can swap this out easily for any other data of my choosing, such as a typedef.
The one exception: event registration refnums. There is no "Show Control" option, and from the front panel it is impossible to update this underlying data type. Instead, you have to create a new event registration refnum in the block diagram. I do find that this makes it difficult to work with, maintain, and debug event registration refnums when maintained in class data.
The request: treat event registration refnums like any other data container type, and expose a "Show Control" option that makes the underlying data type accessible in front panels.
As the number of classes in a project increases it gets harder and harder to figure out which methods in a class are overridden because you need to scroll up and down to compare the methods listed under each class. A distinctive glyph or icon in the project explorer window would be very helpful. I understand that there are workarounds like creating an override virtual folder and moving the overridden vis inside it or right clicking the class and opening the "VI for Override" window and checking if the vi is listed. However, a distinctive icon would drastically increase code readability.
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.
