LabVIEW Idea Exchange

I searched reentrant in this idea exchange and didn't see anything on it so here goes. I would like some sort of indicator showing that a VI is reentrant. Right now, as far as I know, you have to go into the properties and check. It would be nice if there could be either something on the icon, or a small label that would show if the VI was reentrant. Or maybe a slight "halo" around the VI, something to that effect. Any other ideas on how to do this are welcome.

Who doesn't like dumping data to CSV files? But there is a few pain points unless your data is already a string array or the same data type.

The usual way I end up doing it is formatting data to a string, then concatenating it with a delimiter. Then have to figure out if its a new file and prefix the header string. (Its also annoying open file doesn't return an empty file flag (True if New, or Replaced, or Existing AND empty)). 

Then you need to add a new column of data - now there is a problem of keeping format specifier strings and header strings in sync. And then you end up with a stray delimiter so your column headers end up offset from the columns... And your format string breaks if you don't get the format code in the right place. And the data you want to dump increases until you have over 60 columns and its a nightmare maintaining long format and header strings, concatenate strings etc!

It would be nice to format a cluster to a string. Optionally include the header row. For a 1D array could take its name and append the index to it. 

I16 is currently the only output representation of this function, and it is particularly unhandy - I typically end up typecasting it 90% of the time. I propose the output representation of this primitive can be changed via Right-Click Menu.

For most functional blocks on the Front Panel, the wire anchor point is very near the edge of the block (reference this idea for an exploded view of the wire anchor point). This lends itself very well to a trick I use to achieve neat parallel wire routing (until this idea is implemented!😞

Step 1: Wire up a bunch of parallel wires, and you've got a mess!

Step 2: Grab one of the functions, and drag it all the way up and down so that the parallel wires all bend along the same line

Step 3: Grab the wires one at a time, and using Shift+Arrow Left or Right and distribute so that the vertical wire runs are evenly spaced

Here's the problem: Bundle by Name, Unbundle by Name, Property/Invoke Nodes, Local Variables etc. have the "wire anchor point" in the center of the node. This makes the above trick difficult, and it also presents more problems:

Frame 1 shows erratic spacing of tunnels, and a highlighted wire that lands in the center of the large Unbundle by Name. I have drawn a red line that shows the center of the wire run as currently implemented, and the green line shows where I propose the wires should bend. Frame 2 shows what you see when check "Hide Full Names": the wire bends are clearly evident and easy to fix, as shown in Frame 3.

Another problem is "what you see is (maybe or maybe not) what you get":

The three tunnels appear to be wired to 6, 7, and 8, but indeed they are actually wired to 1, 5, and 7.

In a nutshell: When the location of a wire bend is calculated, it should bend halfway between the edges of two nodes. This could be accomplished by placing the wire anchor point at the edge of the node instead of the center of the node.

Who has ever made a cluster typedef, then added some elements, then added more, then a little more? Have you noticed the "typedef explosion" of your block diagram as a result, with constants overlapping other code? Make a right-click option to "link" a bundle by name to a typedef. Note that the two pieces of code below would be identical, but the bundle on left would not suffer from typedef explosion. In addition, have a selectable menu

Another idea is to link the bundle to the destination:

Clusters allow you access to the decorations inside the cluster but you can also drop decorations on a custom .ctl file too but there is not way to programmatically access them.

DVRs are references, and are automatically released when the VI hierarchy that created and "owns" it goes idle (stops executing).  Commonly, the DVR just contains by-value objects, or LabVIEW references that are also automatically released, but an important use case of DVRs is wrapping a non-labview reference that must be properly cleaned-up.   An example is an SQLite Connection pointer that must have a dll method called on it in order to release the database file it is holding open.  Many dlls have similar pointers/handles that need to be properly closed.  This is a headache for Programmers, who cannot rely on a stopped VI releasing its resources, often requiring restarts of LabVIEW to unload the dll.

A clean and easy solution to this problem would be to allow a "DVR Cleanup Callback VI" to be registered with the system when the DVR is created.   That VI would be called if and only if the DVR is release because its calling VI hierarchy goes idle.   This VI would contain the code to cleanup/close the contained non-LabVIEW references.  Could have other uses, such as debugging. 

I have developed multiple APIs that wrap non-LabVIEW dlls, and this feature would be a very significant help.   Please consider it.

Whenever I place a Bundle By Name (or Unbundle By Name) function on the block diagram, it is configured to Show Full Names. But while creating the cluster, I provide descriptive names to each element and so I want that every time when I place the Bundle By Name (or Unbundle By Name) function on the block diagram, by default it must be configured as Hide Full Names.

I know, my wish is not what everybody else wants to have, so better solution to this could be a selectable option (perhaps categorized in Environment setting).

Simple idea is to make the icons found in the palettes, the block diagram and help all match.

The icons in the columns are all the same function, however, there are some significant differences. It is reasonable to expect the help menu icons are expanded to show additional functionality, but there is no reason why the palette and BD icons should be different. The core of the icon in the help menus should be the same too.

These icons screen shots are from LabVIEW 2018.