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

Instead of the two step process of wiring an input on the Connector Pane and then changing the terminal setting to Required through the right-click menu, holding down the Ctrl key while wiring the input will automatically set the terminal to Required.

I know there's a LabVIEW option to set all terminals to Required as default, but I usually use a mix of Required, Recommended and Optional.

Hi all,

image processing is not anymore the "tough stuff"/"niche" of the past. Videos are everywhere now, maybe even more than sounds. So functions that handle video should be included in the cross-platform standard labview, at least for the essential functions (reading/writing files with a minimal set of codecs, acquisition of frames through ip or usb for common protocols, conversion between image format for display and processable data). This would attract a lot of young users. It would also jumpstart future developments of labview in the direction of AI.

Thx

I am making ever more webservices with labview, but I feel I have little control over the server. It can happpen that a webservice becomes unreachable. Sometimes I would be a crashed webservice application, sometimes it is the NI webserver. But no tools available to find out. I can imagine the following tools in the NI webserver API

- start/stop server

- disable/enable server

- enumerate active webservices

- start/stop or enable/disbale webservices

- redirect domain root endpoint to webservice

- set favicon

- some proxy options would be nice to redirect a domain to a specific webservice

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. 

VI Analyzer is great tool but can only perform static analysis on VI (as far as I know). It could be nice to run some tests on libraries / classes or even projects files as well to enforce good practices. 

When we create an input from an output and vice versa, the original name of the control/indicator is copied and a number appended. This usually results in a manual edit of the automatically generated name.

It would be nice to have a customizable list for input to output naming schemes where we can specify keywords and their substitutes...

For example in the form of "Control name" "Direction" "Indicator name"
In <> Out
in <> out
input <> output

Maybe we could even use it for unidirectional naming...
Control > Indicator
Input < Indicator

... or even more complex schemes with the help of regex... But a simple list which looks at the last word and generates a corresponding name would be really nice...

Thanks, Tobi

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

Certain keyboard shortcuts are standard across operating systems and applications. When doing text entry, LabVIEW implements ctrl-c, crtl-v, and ctrl-arrow keys for text selection and manipulation, but does not allow ctrl-a. I have implemented this for string controls. 

I would like to see this be the default behavior for all text entry. 

In LabVIEW, ctrl-a currently selects all objects on the FP or BD. But when the cursor is in an active text field, ctrl-a should select all text in that field. This should include strings, tables, graph labels, control labels and captions, numeric controls and indicators, free labels, and so on, and should work in development and at runtime.