LabVIEW Idea Exchange

Please let me opt out from this new feature, introduced in LabVIEW 2017, permanently in the setup dialog.

Using LabVIEW for a very long time (since LabVIEW 2.0), I never wished such a feature (it got only 27 Kudoes) - and - I am even using it's "anti feature", implemented up to now, constructively to detach objects (Pull control into a structure, connect it to the new target - and "Ctrl B").

This new feature, forced onto everybody, would be less annoying, if pressing "W" would reliably disable the feature. However,  at least in vritual windows machines (Parallels) on a Mac, it does not work 50% of the time.

Take for example an enum that is saved as a type def. The enum has many items (let's say words) of varying length.

In order to see all of the elements, inclusive of the widest one, the array can be sized with the right-click option "Size to Widest Element".

If the type def'd enum is edited, and a longer element is added, the array of enum constants will not size to the widest element. This can be frustrating, as dozens (or more) of these arrays scattered about the program are rendered unreadable.

If the user has previously chosen to "Size to Widest Element", this setting should persist. If the user edits the enum, all of the array constants should size to the widest element.

-------------------------- Example ----------------------------------------------------------------------

This idea is to improve the QuickDrop search window, to return functions that might be betters suited, based on the datatype of the selected function or wire.  Lets say I have a 1D array of numerics selected and I want to reverse it.  I will select the wire, then invoke QD and type "reverse".  But the first item in the list is actually "Reverse String".  With a context aware QD hopefully the search window will see I have an array of numerics, and prioritize the Reverse 1D Array function, and still include the reverse string but maybe push it farther down the list.  

This idea can be applied to the basic data types pretty easily (numerics, boolean, array, string, cluster).  But we could also use this on class wires that are selected.  A class library can have an associated mnu file, which is why some functions you can right click and the corresponding subpalette menu comes up.  So this idea could also prioritize functions that are found in the mnu associated with the class.

When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.

I would like to have the possibility to "negate" some comparison functions such as "Empty String/Path?". This can avoid to add the "Not" operator.

The picture below is a possible implementation. The dot on the input (on the output ok also) is showing the negation.

This might be good to be implemented for the following functions:

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

Once in a while I encounter a case or event list that forces me to grow the structure

- in order to keep the list readable:

It would be nice if the item-list would automatically "wrap" instead.  

Incorporate NI Batch Installer Builder into the general application builder suite.

This tool has a lot of potential for end-user use if it is incorporated into the app builder API and suite.  Batch installers can be used for much more than just installing selected sets of NI software (Which this tool is obviously designed specifically to do).  It could be used for creating installers of multiple, cross-project user installers comprising a complete system.  To do this though, the current batch installer builder needs to be made more generic to be of use.

Specifically:

• Add configuration options to control or disable license dialogs when non-NI provided installers are added
• Add configuration options to control or disable the user/company license dialogs when non-NI provided installers are added
• Add configuration options to control or disable the check for NI updates dialogs when non-NI provided installers are added
• Add batch installer version properties to allow end users to create system versions
• Add support for 3rd party installer inclusion (Dup from another idea, but I had to repeat it here)

Including this in the app builder would be even better since that should allow project based configuration and control of the batch configurations and potentially even programmatic control.

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

Many controls allow you to make scrollbars visible. When a user clicks anywhere within the control, including on the scrollbar, this counts as a Mouse Down. It would be nice if the Mouse Down event would indicate whether the click was on the scrollbar or on the actual clickable area of the control, so you could do different actions based on which it was. Of course, you can usually do manually by checking boundaries of the control against the coordinates of the click, but it seems like a common thing so it would be easier if the check was built in.

The LabVIEW IDE may coerce diagram constants when the enumerated typedef changes.  The problem is: the constants may occur in many places, and the coerced value is not necessarily helpful.

In the pictures below, the "Idle" element is removed from the typedef and the IDE coerces the diagram constant to a neighboring value "triggered".

Now the program behaves as if triggered. 

When a diagram constant becomes invalid, wouldn't it be better to flag it as broken, so that the programmer is forced to handle the problem?

After reading Restore High Contrast Icons I procrastinated as long as possible before installing LV2016.  When I finally did, I was disappointed by the additional space required for the palettes; all of them!  I have been using LabVIEW since 5.0 and switched to an Icon view of the palettes shortly after getting comfortable with the graphics.  Now, I have to move my mouse further to get to each sub-menu and VI selection.  It's a waste of developer's time and apparently done for absolutely no good reason except to make a change; very similar to the washed out icons.

This extra space needs to be removed or at least an option provided to set the spacing back to the condensed spacing always available.

These images to show the relative size of the palettes LV2016 vs. 2015.

Controls Palette

Functions Palette

Yes, this might seem trivial, until you think about traversing several palettes to get to your needed VI.

*Random example, if one were doing FTP development they'd pin the menu.

** The original size of the above graphic is 1030 pixels wide; less than 800 for 2015.

Quit messing with what works and has become the standard with regards to options.  At least when that ridiculous "default" setting for icons instead of terminals was introduced we could undo the setting in Options. 

It seems that NI has hired some non-G experts to mess up the interface simply so they can enumerate all the "great" improvements they've made.  Or, was all the extra space to make sure newbies couldn't miss the folder tab, since connecting the "right arrow" on an icon to it being a sub-folder would be too difficult for children?

Overlay drawings are super useful for highlighting regions of images, but sometimes just a solid line is not enough. I'd like to be able to change overlay line types between Solid and a dashed or dotted line. Color isn't always enough to discern between different overlays and I think line styles would help with that. I've considered how to do it myself, but it seems like it would probably take much longer to compute segmented overlays than something built-in. 

The label should be hidden as standard on This VI referrence as it gives no extra information, it only clutters the block diagram.

/Y

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.

Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!

In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.

Here is a simplified example to illustrate the problem (see picture).

In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.

However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course ). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!

What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.

The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.

Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.

(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)

Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.

                                            "Build Path" should be Growable

                              something like this,

A picture is worth a thousand words.

Basically I'd like more control over the text in listboxes.  I want the same level of control that you can get from a string control, where each character in a string element can have custom font settings.  At the moment each line in a listbox must have the same settings.  This idea is to have more control over the font settings of listboxes, and multicolumn listboxes, as well as implementing the property nodes that allows for these settings to be controlled problematically.

It'd be great if you could hide or just show the 1st letter (and thus color) on the left side of a IPS, forcing both often gives no extra information and steals a lot of space.