LabVIEW Idea Exchange

This idea came to me from Darren's Nugget 2-23-2018 on Data Agnostic Probes I thought it might be useful to write a Probe.vim or specifically, a data type malleable probe to gain the ability to have some access to the data itself in a general smart probe and maintain the ability to display the data in a type specific manner.

One example would be a "Data History Probe" that displays the history values of any data type.  I'm sure there are other good uses.

Estimate and show the Time Remaining during LabVIEW Installs, using selectable and realistic time units:

.

I remember when I first discovered the "Show Item Paths" option in the "Project" menu. This is such a useful view, but for some reason we are only seeing the tip of the iceberg!

I propose that the project window be enhanced to support other useful VI properties too:

Among other things, this would allow us to very easily identify VIs (or controls, or libraries, ... ) with non-standard properties. (Have you ever revisited an old project and tried to figure out which VIs are reentrant, or inlined?)

What properties should be available?

• Ideally, this view would support ALL properties for ALL project items ( - at least those that have a compact text representation).
• If that proves impractical for some good technical reason then I'd suggest we at least get access to the Execution properties.
• It would be great if we could choose which columns to display from available item properties. These columns could then be toggled on/off (just like the existing "Paths" column):

An added bonus would be the ability to sort by any column:

• My preferred implementation would be to allow the user to click on any column name to toggle between ascending and descending view. (This type of thing has been suggested a few times for multicolumn listboxes...)
• On the other hand, I'd be happy enough if this worked the same as it currently does with "Paths", i.e. using the "Arrange By" option (>> Right-click on a parent item in the project and arrange the child items by Name, Type, Path, etc)

I think this would be a BIG step in the right direction towards leveraging the existing project interface to provide some REALLY useful information.

In LV 2010 the string constant display style is a nice new addition based on the ideas here and here.

The implementation is consistent with how the radix indicator works on numeric constants in that you must navigate to the visible items shortcut menu and turn them on discretely.

If I want to take a string constant, show it in '\' format and turn on the descriptor, it requires two separate operations.

I propose that the descriptor (or radix for numeric constants) be automatically shown when displaying any mode other than the default.

Not only would this add to the readability of these constants but would eliminate the extra step to have to discretely show this valuable piece of self documentation.

If the developer did not want the descriptor shown, they they could manually turn it off.

Three graphs contain the word "waveform":

• Waveform Chart
• Waveform Graph
• Digital Waveform Graph

(... and equivalent graphs in the classic and silver palettes ;))

This is misleading because these don't just work with waveforms, but with a rich selection of other datatypes. Then the word "waveform" is very long and the default label invariably gets in the way of structure borders and other code elements.

I suggest to drop the word "waveform" from all graph types that contain it. Now we simply end up with the following labels:

• Chart
• Graph
• Digital Graph

 (... and equivalent changes in the silver palette.)

Ahh, so much more concise and compact!!! I feel better already!

Idea Summary: Drop the word "waveform" from the default label of all graph types that contain it.

Thanks for your support!

Structures have many right-click options, but the property dialogs are currently very sparse (only label and subdiagram label). Let's compare the current right-click options of a FOR loop with the actual properties dialog, and we can see that many useful properties are missing (visibility of conditional terminal, autogrow setting, etc.). The parallelization has it's own standalone dialog, why not have all these settings on a new tab instead?

I propose that these scattered properties should all be integrated into the single properties dialog to keep things better organized. Here's how the properties dialog of a FOR loop could look like after implementation of this idea.

Similar changes could be made for all other structures.

There's a lot you can do with LabVIEW to improve the appearance of the UI.  The community has really helped move the LabVIEW UI frontier forward with many wonderful UI palettes and tools to improve UI creation and customization.  One key limitation to all of this though is that LabVIEW controls are comprised of parts that are NOT programmatically accessible.

This is a large drawback since it prevents developers from creating dynamic UIs.  For example, you cannot really add a good "Dark Mode" feature without designing specifically for dark mode because Frames and other control components are not customizable at runtime.