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

I am extensively using the Array to Spreadsheet string Primitive and most of the time I never used the Format string input (Use to wire an empty string constant) and still I am getting the right result what I expect. So I think it would be better if the Required Terminal is changed to an Optional Terminal.

It is known that the Array to Spreadsheet string is Polymorphic, but when we wire an array of I32 and DBL the output string is DBL format only. It would be good if the output String adapts the data type that is wired unless otherwise specified by the Format string.

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 a large base of compiled executables. One computer is encountering a "not enough memory to complete this operation" error. I'd like to drop a debug version of the executable on their computer and see if I can monitor which VI is using all the memory similar to DETT's remote monitor abilities.