LabVIEW Idea Exchange

My idea is very simple - I'd like to see new size(s) indicator available for arrays, so user may know which dimensions his/her array has. The necessity partially arises from this thread. In that case the array looks visually empty but really contains some hidden row or column and there's no way to know about it except for calling Array Size instrument on it. Also it would be good for the developer to see the exact number of elements in the array on FP or BD.

I suggest this new context menu item:

The indicator might look like a common LV indicator like this one:

I know that its implementation adds one additional operation in IDE mode but I think it should be fast enough to work smoothly.

Working with applications with 5000+ VIs means a lot of folders, libraries and classes. Normally you work on a specific class for a while, or perhaps a method of that class. But every time I have to restart LabVIEW for some reason I have to do a lot of clicking to get to a specific VI. If I'm lucky it is in the Recent Files list, but many times I'm working on more VIs than the list contains and have to click same path down in the project, over and over again.

Wouldn't it be sweet if you could right-click on a VI/class/lvlib/control and select "Create shortcut" and a link to the item in the tree is created in the "Shortcut" folder? Right-click on a shortcut and select "Remove shortcut" and it's gone.

I also have VIs in my project that I use often (for example a GUI showing all modified VIs in the project, where I can mark VIs and lock them in Subversion) and they would always "hang out" in the Shortcut list. So perhaps it should be possible to mark items in the shortcut list that are permanent and follows you in all projects.

I propose that if an array is wired into a for loop, the tunnel should be auto-indexing by default (current behavior) UNLESS there is already an auto-indexing input tunnel in that for loop (new behavior).

Generally, when I wire an array into a for loop, I want an auto-indexing tunnel, so I am happy that it creates one by default. However, when I wire a second array into the same for loop and it creates another auto-indexing tunnel by default. This is usually not what I want because it will cause the loop to stop early due to one array being smaller. I'm afraid that this default behavior may cause bugs for new programmers because they may not realize to change it (in fact, this has even happened to me before). Default behavior should be the "safe" behavior. Making the decision to have more than one auto-indexing input tunnel in a loop is one that should be carefully considered, so it shouldn't happen by default, but rather should be changed explicitly by the user.

I know there have been many ideas posted about the current auto-indexing default behavior, but I didn't see this specific one anywhere, and I think it is an important suggestion.

Now that the SSP package is delivered on USB instead of DVDs (good stuff!), I have a minor request: Could you have the USB label include a release/version name on its label?

It might add too much of a cost depending on how you get them customized, but if that is not an issue it would be very practical to be able to see what the USB contains by its label (as we could with the DVDs).

On a side note: Many companies have strict regulations on the use of USBs, and the need for such has increased with weaknesses like BadUSB. Perhaps NI could state something about how the USB sticks they send out are protected, either in the delivery package, or just as a statement on ni.com? That way people who need to convince their IT departments to allow them to use the NI USB sticks will have something to show (I'm sure you will have to add some legal disclaimers there as well , but that's OK).