LabVIEW Idea Exchange

Idea Part 1: The menu that appears when right-clicking an input of the Replace Array Subset node should contain Add Input and Remove Input options.

Idea Part 2: The QuickDrop Remove and Rewire tool (Ctrl + Space, Ctrl + Shift + R) should remove unwired inputs of the Replace Array Subset node.

This would be similar to the menus of several other well-loved nodes, such as the Build Array node.

Real-world example

The other day I wrote the following code:

Initially all the inputs of the Replace Array Subset node were wired. Then I realised I had made a mistake, and needed to remove the third-last pair of wires. I deleted the wires. So far so good.

I then selected the node and pressed Ctrl + Space, Ctrl + Shift + R to execute the QuickDrop Remove and Rewire tool, in the hope that it would eliminate the unwired input. It didn't. I then right-clicked the input, hoping to manually select Remove Input. That option didn't exist.

The only option I had was to manually disconnect the last four wires and reconnect them one input above, followed by removing the last input by dragging the bottom edge upwards.

Having to manually disconnect and reconnect wires was a little disconcerting. I wondered: what would have happened if I had made a mistake with say the second input, instead of the third-last input? A lot more manual wiring would have had to be redone.

Notes

• This idea is deeply related to the following idea: Add "Add Element" and "Remove Element" to the Index Array context menu. However, I arrived at it independently during recent real-world work, as described above.

The Wire Multiple Objects Together QuickDrop tool (Ctrl + W) is extremely useful. However, at the moment it has the following limitation.

The other day I found myself writing code like the following.

Naturally I tried using the QuickDrop Ctrl + W tool. However, it produced the result seen below, which is not what I wanted.

The Ctrl + W tool wires each source wire to a compatible (coerceable) destination. In the example above it wires to I32 and DBL destinations indiscriminately.

The desired outcome would be achieved if the tool preferred wiring to destinations that match the source data type exactly, before considering other compatible (coercible) destinations. In the example above, the tool should prefer the DBL destinations. It should wire to the DBL destinations first, before considering I32 destinations.

Notes

• The example above shows 10 wires being wired between the Index Array node and the Replace Array Subset node. The real-world VIs I was programming the other day required wiring multiple pairs of Index Array and Replace Array Subset nodes, some with as many as 30 wires between them. Wiring them manually was a tedious and time-consuming operation.
• This idea is somewhat related to the following idea: Improvement to the QuickDrop Ctrl+W tool: Wire constant to multiple destinations

Problem: Many native VIs use the Non-reentrant execution reentrancy setting.

Solution: The vast majority of native VIs should use the Preallocated clone reentrancy setting.

• The native VIs that need to use Non-reentrant or Shared clone are few and far between - they should be identified on a case-by-case basis. Their Context Help and/or Detailed Help should explain why they need to be set to Non-reentrant or Shared clone.

The following is a selection of vi.lib VIs that should use Preallocated clone. This selection is meant to serve as a starting point and is not comprehensive.

Notes:

• This idea is related to: The reentrancy of new VIs should be "Preallocated clone" . They both argue in favour of using the Preallocated clone setting more.
• A significant number of native VIs are already configured to use Preallocated clone, which is great.
• There are curious cases where closely related VIs are set to different reentrancy settings. For example, Color to RGB.vi is rightly using Preallocated clone, while RGB to Color.vi is Non-reentrant. Similarly, Trim Whitespace.vi is rightly Preallocated clone, while Normalize End Of Line.vi - which lives next to it on the String palette - is Non-reentrant.
  • This suggest that the reentrancy setting of some native VIs was chosen haphazardly. This needs to be rectified.
• The fact that so many native VIs are non-reentrant partly defeats LabVIEW's remarkable ability to create parallel code easily. Loops that are supposed to be parallel and independent are in fact dependent on each other when they use multiple instances of these non-reentrant native VIs. When an application uses multiple instances of these native VIs it is as if there are "hidden semaphores" that are added between the various call locations that call these native VIs. This leads to less performant applications (more CPU cycles, longer execution time, larger EXE compiled code size).

The connector pane is a very useful feature for defining what the parameters for the VI are, therefore how it interacts with its environment.

On the other hand, the development experience did not age well. The 32x32 icon that is divided into smaller areas based on the pattern selected for the VI feel small on today's screens. On top of that most of the functionality is hidden behind the context menu.

This feels like a lacking experience for a crucial feature, but we grow accustomed to it, there we do not complain. But that doesn't mean things cannot be improved.

I would personally prefer a new window being opened when I want to edit the connector pane. The pane itself could be represented with 5x magnification (or even better, user selectable): 160x160 pixels.

On the pane, we could have a dedicated drop down that facilitates the selection of the pattern.

On each connector we could have a border representing its current state: Dynamic dispatch/Required/Recommended/Optional.

Cycling trough these states would be available on left click, for example, and reversing the direction with a shortcut, like ALT + left click.

Connecting the front panel terminals to the connector pane could be done by dragging and dropping to the desired place. To make sure that mistakes do not happen, the drag operations shall not move the front panel controls on the panel itself.

To make the workflow as smooth as possible buttons could be added to Apply the new connector pane, Apply and reorganize the front panel, Reorganize the front panel or Cancel the whole operation.

To make sure that we don't lose existing functionality the CTRL + left click shortcut shall keep the swap terminals functionality (a.k.a.: switcheroo).

Removing controls from the connector pane could be done by the right click, or left click for selecting the terminal and then using the Delete button on the keyboard.

Other operations inside the context menu, like the rotate by 90 degrees, add terminal, remove terminal, etc. could be made available via the menu of the window. I personally use these less, but if there is need for them, then we can discuss how they shall be presented on the window.

Since this idea was formulating over a long period of time in my head, but by no means lot of tought put into it, I'm very open to discuss the details. And, by no means the only or best solution to improve the Connector Pane UX.

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. 

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

A number of people, myself included, have found it necessary to parse ISO-8601 time strings into time values. The ISO standard has a lot of options, so a complete solution is pretty time-consuming. It would be nice if the string parsing functions in LabVIEW included a format specifier that allowed parsing of ISO-8601 time strings directly.