LabVIEW Idea Exchange

A Context Help annoyance: when I hover over an enum, it graciously provides a wealth of information about the datatype I have chosen for the enum. So much information, actually, that the information I'm after - the items - are cut off by the window. How about a shorthand data representation?

Very simple idea that can make locating the basic comparison functions more efficient (first two lines). Changing the order putting each comparison function and his counterpart below him would make easier to find the desired one.

Now:         Proposed: 

There are many times when I need to grab the last element or last n elements of an array.   This usually involves a call to Array Size and then a subtraction, costing me time and block diagram clutter.  Array reversal is essentially free, but again costs clutter and clicks.  For common array types I have personal VIs to do the job, but that is just a band-aid with the proliferation of data types that I use.  My idea would be to treat negative values input to the index array or array subset VIs (for example) as counting from the end of the array.  The last value would have index -1 and so on.  To get the last n values I would put -n into the Array subset VI and that's it.   For


expanding 
the 
Array 
Index 
VI, my preference would be that it counts down (-2,-3,-4,...).

Hello,

I would like to suggest that LabVIEW support HDF5 for data format, file storage and data transfer.   I would to suggest the support include maintenance to coincide with new and future versions of HDF5.

Thank you.

We can specify custom markers for axes, but even if we do so, there will be two additional markers that cannot be hidden: the Min and Max!

I would prefer an option to get rid of these two extra markers. Often they are distracting and not desirable for a clean look. For example we might want the x-axis to start at zero, but we want some padding to the left so data points (e.g. small circles) are not cut off by the other axis. Here we might want the x-axis min to be e.g. -0.02, but we still want the first maker to be at zero with no markers to the left of it.

If I specify custom markers, these are the ones I want, nothing else. 😉

I, like many others I am sure, have multiple LV versions installed on my computer.

I have often wished for a small launcher program (linked into Explorer.exe under Windows) which has a peek to see what version a VI (or ctl or whatever) is BEFORE calling the respective LV version.

It could also have an option to show a dialog whenever a VI is double clicked in a version different to a version of LV which is ALREADY open asking if it should be opened in the native version or in the currently opened version.

An alternative would be to treat VIs opened from a different version as locked (read-only), forcing either a manual setting of write permissions or saving under a different name.

Shane.

Okay so lets say you have a VI that you developed, and works great on its own.  You have some nice scaling and control manipulation with panes and custom resizing code.  All works great.  Then you realize this might be handy to have in a subpanel.  So you insert it into a subpanel, which itself can be resized at runtime.  The only problem is, if code isn't written to handle the resize of the Subpanel properly, then the user could accidentally make the subpanel smaller than the minimum VI size that is inserted into it.  At which point the UI will get messed up and making the subpanel larger will not bring it back to the desired look.  Here is a thread where I post a simple example.  If the subpanel is set to fit to a pane, then you could programatically set the minimum pane size, to be the same as the minimum front panel window size, of the VI being inserted.

But if the Subpanel isn't in a pane, then there could be other issues.  So this idea is to have a property of a Subpanel that is "Minimum Subpanel Size".  Which will not allow the control to be smaller than a set size.  To make things even easier I propose a property that is "Set Minimum Subpanel Size to Minimum Front Panel Size".  Now when you try to make the Subpanel too small with a property node, it will generate an error, just like if you try to set the Front Panel too small with a property node.  And if the Subpanel is in a pane and being resized, this would prevent the control from getting smaller, and prevent the pane from getting smaller.