LabVIEW Idea Exchange

I don't like the way that long file paths are shown in path controls and indicators:  If the path is longer than the textbox (and it usually is!), the user only sees the first several levels that fit.  This can be pretty confusing.

One way to solve this issue is to truncate the path in the middle in such a way that the filename or last folder (which is usually what's most important) is always shown.  I've seen this in other UIs and it should be a natural thing for users to understand.

Here's an illustration:

I think this should be a built in feature of the path controls and indicators, accessible through right-click menus and/or the properties menu of the control at edit time.

I think structures should have a better label system. Currently I use free labels of the same color as the loop which looks great and makes the code easy to read and debug. But if I resize my loop I have to manually resize the label as well. I think this should be built into a right-click option.

(structure) rick-click » visible items » Structure label

Large string constants, like to one shown below, can really get in the way. I would like to double-click the border and have it collapse, like the LV 2010 Cluster now does. Putting large string constants in a VI, or rolling them up, are some work-arounds, but this would be easier...

                                 Double-Click the "text" icon to reverse.

Currently, the block diagram has an endlessly useful feature. I use it every day - the Distribute Tool.

The following feature would be AWESOME for expediting BD readability:

It'd be usefull for develloper and especially application user to improve graph control by adding to Graph direct access to Plot Visible property on plot legend.

For the time being, you have to go to color and choose transparent or to change visible property dynamically.

I propose control like that ... but we could find another idea to access Visible property.

...the ability to bulk-create References, Local Variables, Property Nodes...

My idea is simple: Put the connector pane on the front panel next to the VI icon.

Why: Right clicking to show the conpane means extra clicks that would not be necessary if it was always there.  It would also be solve the problem of saving the VI with the connector pane hiding the VI icon.

Make possible that Boolean function accept error cluster as input as this example:

It could be nice to have a context help on coercion dots to see what is the expected type of the data that is supposed to be wired to. This way you can rapidly determine what kind of conversion to use to avoid the coercion dots.

When creating a subVI from a selection, LabVIEW should do two things:

1. Use the user's default connector pane pattern instead of selecting one matching the number of inputs and outputs. This will make easier wiring and allow users to add more IO later.
2. If the user is using a "standard" pattern (e.g. 4-2-2-4), LabVIEW should try placing the error clusters at the bottom corners and objects or references at the top corners.

It should also try to make the FP of the subVI cleaner, but that's another matter.

It should be nice to limit the action of Ctrl-B to a selected part of the block diagram.

For the moment the Ctrl-B removes all brocken wires in the complete VI.

Sometime when you have a case structure with multiple cases ... and when you have multiple brocken wires in many cases ...It is usefull to keep non visible broken wires...

The broken arrow (list of pending errors) will then help you to find all locations to modify. 

More often than not, one location doesn't work for both. Here's an idea:

In line with giving us a better polymorphic VI editor, doing the same for Enums would be great.  The current implementation is SSSLLLOOOWWW and unwieldy.

Please re-visit this functionality to make our lives easier....  So many people create enums via rings for exactly this reason.  This is just unneccessary.

The current boolean diagram constant is potentially confusing and too elaborate.

Confusing, because it almost looks like a toggle switch, so the new user might click on the right half, expecing an unconditional FALSE. However, there are no active areas, and an inversion of the current value occurs no matter where we click.

Too elaborate. All we need to see is the current value! Why do we need to see the "other" value greyed out??? We can guess that by simple elimination. There is too much redundant information, wasting twice as much diagram space than actually needed to display relevant information. The current design also makes e.g. 2D boolean diagram constant very confusing. Have a look at the image. Can you immediately tell that the 2D array on the left is only true on the diagonal? (I did not think so!). Now look at the suggestion on the right. Ahh... much better!

 Suggestion:

The boolean diagram constant should be smaller, simpler, and cleaner.

The image shows the current design on the left and the suggested design on the right.

What a difference in clarity and economy!!

When an array leaves a loop with indexing enabled, you get an array which has one more dimension, but quite often you want to concatenate the data to an array with the same number of dimensions.

If the subarrays have the same length, you can use reshape array, but usually they don't and you need to do something like below.

It would be very useful if output tunnels for arrays had an "Enable Concatenate Indexing" option as well, as depicted below, which would do this.

Clusters are powerful and necessary, but they can easily clutter up otherwise immaculate code.  Why not have a "View As Icon" option (a la Express VIs) for cluster constants?

Right-click menu change...

There have been similar suggestions, but I think we need a clean, simple solution.

I would like to be able to see that a constant is linked to a typedef without clicking it, especially enums.

This could be a light border around the constant, marching ants, or a flag of some type such as the example I have posted. You can quickly tell that the top enum is not linked to a typedef, whereas the bottom one has the little "td" flag.

 

Auto-indexing of arrays in for and while loops are a nice luxury in LabView.  One option that could save much time would be a menu option to turn on conditional indexing, this would expose a boolean terminal under the auto-index icon to select if the current itteration should add the itteration to the array or skip it.  From an execution standpoint there would only be a minor performance hit (could still preallocate max array size on for loops and automatically return used subset).  This could also work for autoindexed in but would have less use that the autoindeded out case.  I know I have built many conditional arrays inside of a for loop and it requires a case selection and a build array making the code less readable and requires time and thought.  It can also be less efficient than a compiler can do.

See the example below which would run a for loop and only build array of < 0.1