LabVIEW Idea Exchange

Pop up on a subpanel control. There's an option for "Make Panel Transparent". When you enable that, the background of the panel is transparent and you can see controls/indicators underneath. The key word here is "see". You cannot click on those controls. The subpanel eats the mouse clicks. I talked about this with a couple people and could come up with no use case where you would want a transparent subpanel and not be able to click on the controls behind it. What I think the behavior should be is "if the mouse click hits a control in the subpanel, that control gets the click. If no control in the subpanel gets the click, the click falls through to the controls behind it, if any."

When using a case structure within a loop for a state machine, or when using an event structure, it is frequently necesary to either add a new case/event or add a new state variable to the structure.  This can lead to unexpected behavior if the user has accidentally used "Use Default If Unwired" on an output node, and will require time consuming wiring of all cases otherwise. The Linked Input Tunnel Option helps with this.  However, the mass of state variable wires, if there are several, still creates a confusing and cluttered diagram.

It would be nice to add a "Feed Through if Unwired" option.  This would allow us to wire ONLY the variables that need to change, and only need to examine the relevant cases.  Additionally, you would get a nice clean diagram.  Here is one idea, shown for an Event structure:

In large &/or dense &/or multi-dimensional arrays, it'd be helpful to be able to tell the location of elements without having to either manually count or use the index values to relate to an element's location. A default tip strip could work - see image below:

When building an application, the build will fail if any of the VIs are broken.  But, the build doesn't fail until very late in the build process.  It would be great if the build would fail right away if any VIs are broken.

Note: In one of our big applications, it sometimes takes 30 minutes into the build before the build fails.  However, it only takes a couple minutes to detect this by loading the VIs into memory and testing if they are broken.  So, as part of our one-click build, we implemented a pre-build test for broken VIs and abort the build -- this saves us a lot of time (in cases where the build is broken).

The ctrl+drag and ctrl+alt+drag shortcuts for adding and removing space on the BD are super awesome. But I think they would be even *more* awesome with the following tweak:

Limit space addition/removal to the visible diagram; i.e. don't make any changes to other cases in a case structure.

I have had many situations where I was doing cosmetic tweaks in one case of a case structure, only to find I have overlapping items in another case that I wasn't looking at.

Hopefully this simple animated gif demonstrates what I'm talking about.

(And yes, I know we could enable "auto-grow" on the case structure to eliminate the shrink-case-smaller-than-contents problem, but that still doesn't address all the potential issues here.)

Searching an array for a certain element can be expensive for large arrays. The speed could be dramatically increased if we can assume that the input array is sorted. The speed difference can be several orders of magnitude.

There is an old example that discusses this in more detail. I also wrote a similar tool long ago when I needed to recursively score positions for the tic-tac-toe solver, using a retrograde analysis similar to what's used to generate endgame tablebases for chess. (It literally took hours with the plain old "search array"!).

(A similar tool is the "search ordered table.vi", which only works for DBL and returns a fractional index.)

Suggestion:

"Search array" should have a boolean input (default=FALSE) where we can tell the algorithm that the array is sorted.

(The output would be exactly as before, with -1 indicating "not found".). Setting this input to TRUE would switch to a binary search where in the worst case only ln2(N) instead of N comparisons need to be made. (e.g. 20 instead of 1048576 for a 50000x speedup!!!)

It could look as follows.

Of course it should continue to accept all possible datatypes (including clusters) and not be limited to simple datatypes as the polymorphic example quoted above.

I have been pretty slow to pick up the addition of quick drop functionality. This is mainly due to the list of shortcuts being out of the way.

I have always thought it would be easier to get the hang of Quick Drop if I had the option to put the quick drop shortcut in parenthesis next to the object name in the function pallet.  That way when I go back through the "normal" way of programming I will see the shortcut each time and over time I could get the hang of each objects shortcut. 

Currently enums can not be in a cluster that you want convert to JSON. It would be great, if this could be added.

Either the enum value could be converted to its internal representation (e.g. u16) or the value could be saved as a string (make it easier to read the JSON and parse it outside LabVIEW).

The unflatten should be able to handle the u16 easily to convert back to enum or take the string and search through the enum of the datatype that one has to connect to the vi. If there is no match the VI can issue an error.