LabVIEW Idea Exchange

After working with text-based languages recently, I've become more aware of a very painful flaw in the LabVIEW IDE.

First of all, as software engineer, I like to perform experiments. Make a small change, test it. If it doesn't work, then just use Git to roll back the changes. I've been doing this for years, and with LabVIEW it has been fairly painful. Until recently I didn't realize there was a better way.

Why is it painful? Everytime I use Git to check out a different branch or roll things back, I am forced to close LabVIEW or at least close the project so that LabVIEW detects and loads the new code from disk instead of whatever it has in memory. I lived with that for years because I didn't know any better.

Enter text-based programming and IDEs: VSCode, PyCharm, probably any other modern IDE. I try an experiment, it doesn't work. I roll the changes back in Git and guess what? I don't have to open and close anything! The IDE just automatically detects the file has changed and loads the new file!

When is LabVIEW going to get with the times?

You cannot currently install MAX as a standalone product- you need to install it along with something else. I need MAX on basically all computers I build my installers for, so I always go into the Additional Installers menu on the Application Builder, then pick (usually) "DAQmx with Configuration Support". Unfortunately, this also means I have to uncheck "Automatically select additional installers" so I can go find the "Configuration Support" item.

I almost always want to let the App Builder pick my additional installers for me, so I will check "Automatically select", then uncheck it, then go check the box for "...with Configuration Support" for one of the items that got automatically selected.

I'd like a box that lets me prefer the "With configuration support" version of whatever I'm building so I can make sure MAX gets installed. For my use, it doesn't seem to matter if I pick "DAQmx with config support", "VISA with config support", etc.

I'd ask to make MAX a standalone installer, but that would require me to uncheck the "automatic" box to add MAX to the list, which doesn't really help. I just want to say "Hey Appbuilder, figure out whatever you need, and ALSO install MAX."

Pro-grade mockup shown below:

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

The asterisk (*) that LabVIEW automatically places in the title bar when a file is modified should be placed first not last so that it can be seen when the window is too narrow to display the whole string, e.g. where other programs like Notepad.exe put it when then text truncation is indicated by an ellipsis (...). Some titles can be much longer when they include lvlib and lvclass contexts.

I understand that empty interface boxes should reflect their purpose, but this design decision wastes too much block diagram space. When using interfaces, explicit type casting is often necessary by definition. Unfortunately, this quickly clutters the block diagram.