LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

As the number of classes in a project increases it gets harder and harder to figure out which methods in a class are overridden because you need to scroll up and down to compare the methods listed under each class. A distinctive glyph or icon in the project explorer window would be very helpful. I understand that there are workarounds like creating an override virtual folder and moving the overridden vis inside it or right clicking the class and opening the "VI for Override" window and checking if the vi is listed. However, a distinctive icon would drastically increase code readability.

View All (2)

Hide This VI label as default

View All (1)

Since LabVIEW 2017, the default build specification check the option "Allow future versions of the LabVIEW Runtime to run this application".

I don't undertstand why it is checked by default when you read the help that said "Disabling this option prevents any changes to the performance profiles and helps you avoid unexpected problems resulting from compiler upgrades."

Because NI and me doesn't know the future, NI will never garanty that your application will run with all the future LV Runtime. I know it well because I'm facing this issue with le LV RT 2020 that breaks the execution of different application that I have buid in 2017 SP1.

The behavior is a little strange too, because, even if you have the run-time use to build the application on your computer, the application will use the highest one present one the computer.

This options can be very usefull, and I appreciate it, but maybe we need to have more control on it. So my idea is to give to the user the ability to list supported or unsupported LabVIEW Runtime.

This will help us managing future LV Runtime without having to recompile the application which seems to be the goal of this option.

for Example :

[MyApplication]

ExcludeLVRTe = "2020,2021"

Regards

I often use LabVIEW projects. Projects may contain libraries, classes, etc.

Changing the contents of any component (such as a library) within a project causes the project file to change -- even though the project definition itself shouldn't have actually changed. For instance, if this is my project:

and I delete a VI that is inside an .lvlib, the project file itself claims to have had an attribute change:

In theory, this top-level project change isn't necessary -- since the project should just reference the library, and only the library should reflect a change.

These unnecessary file changes make it trickier to deal with source control, merging code, tracking changes, etc, along with adding one more file that you get prompted to save every time you close a project.

Replace icon of method overrides

Similar to the library banner functionality, I find myself wanting to replace the icon of method overrides with the icon in the parent. This is done automatically for new overrides, but I haven't seen any way to apply a new parent method icon to its overrides once they exist already.

I imagine this working like the library banner: whenever the VI icon of a dynamic dispatch VI with overrides in memory is changed a dialog could pop up and ask if you want to apply it to the children as if the icon had been freshly generated the way it is for new overrides.

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!

View All (2)

Wire values on Mouse Hover

I sometimes feel difficult to see the value of a wire while editing the VI. When "Retain Wire Values" is turned ON, I need to put a probe on that wire to see last executed value. Applying probe on every other wire while coding will result in lot of probes and also it will increase the coding time.

Having a way to view the wire value on Mouse Hover in edit time will be really useful. What I feel is, the value can be displayed as a tooltip or a dialog box similar to context help window which will disappear when mouse pointer is removed from the wire. 🙂

wire hover.JPG

View All (7)

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.

View All (3)

What's wrong with the current LabVIEW Fonts option dialog? Plenty!

Let's have a look:

We can only see one of the three font groups
It does not tell us the name of the current font, just how it looks!

If we specify a custom font, we get a dialog that has confused me since I started out with LabVIEW 4.0 way over 10 years ago.

Especially the two checkboxes in the lower left corner have bugged me since day one, because they are very confusing.

If we open this dialog from the options menu, both boxes are unchecked.
If we open this dialog from the BD or FP font pulldown, one of the checkboxes in inoperational, but not greyed out. Why???
Unless we read the help, it is not clear what they actually do and what they actually show.
Do I click these to make whatever I have selected the default or do I click these to revert back to the default???
...

This font dialog needs to go and be redesigned from scratch!

IDEA:

Why not make the Font options a bit more intuitive. Here's a quick draft. Even if we select the default font, it should show what it is but have the parts on the right greyed out.

It probably would need a small preview area below each selection (not shown). Each can be much smaller than the current preview window. (It does not matter if a 500pt font is clipped a bit.)

Message Edited by altenbach on 07-28-2009 09:41 AM

Download All

View All (3)

Display Format Glyph for Timestamps

String containers have display format Glyphs to help us understand the String Values when the display is Normal, Hex or Escape codes.

Integer numeric type containers have them too to show radix.

Timestamp containers must be inspected for their display format property to determine if they are in System Time or UTC.

Timestamp Controls, Indicators and Contsants SHOULD have a similar optional display format glyph.

This could be used instead of the misleading coercion dots when operations are performed on Timestamps as Seen Here

View All (1)

TL;DR: the idea is please make building as fast in new LabVIEWs post 2023 Q3 as old ones when you have a clear compiled object cache and when your file timestamps have changed.

LabVIEW 2023 Q3 includes a major change to the app builder:

LabVIEW 2023 Q3 has improved cache behavior for packed project libraries and applications.

The first build will populate the cache, and then the subsequent builds will be much faster.

Great! It is pretty easy to confirm this and it works! Unless...

1. File timestamps change - such as when you clean a directory and clone project files in your CI job

Git does not make file timestamps match "commit date" - when you clone fresh all the timestamps are now o'clock, when you change branches all the files that change are reset to now

2. The cache is cleared prior to the build - such as when you want a repeatable build unaffected by prior state so you set your CI jobs to clear it before each build

3. You are doing a "first build" on a new project - such as when you use a container or VM disk image to reset the entire environment to a clean state prior to your CI job

In all my testing, any of these conditions pretty strictly cause builds to be slower in LabVIEW 2023 Q3 than in earlier versions: with a clear cache by typically ~60%, with new timestamps and a persisted cache depends on how much of the code has new timestamps.

In other words, I expect most everyone using CI will find building slower in 2023 Q3+ than later versions. So, the idea is: whatever optimizations were done, include an option to revert to the old behavior - build spec, config ini, editor option, whatever.

View All (8)

Jog-wheel (unlimited range knob)

Hi,

I suggest adding a jog-wheel (unlimited range knob) to the palettes:

The current knob you set the minimum and maximum range, and can then select inbetween those values by turning the knob from one endpoint to the other.

A jog-wheel you configure with only the range for one complete revolution of the knob, but you will then be able to turn it as many revolutions as you wish and it'll continue to increase or decrease its value (depending on if you turn it CW or CCW). This'll work like the jog-wheel on a video-player; configure it for a range of 10/revolution for instance, if you then want to move 30 upwards, you just turn the knob three full revolutions CW. It should support the mouse scroll wheel on top of it of course, for "quick jogging".

Cheers,

Steen

View All (10)

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.

Control Parts.png

View All (2)

Build 32-bit executable in 64-bit IDE

Currently, it's not possible to build a 32-bit application using the 64-bit IDE. The work around is to write your code in the 64-bit version, and then open it in the 32-bit version to build the executable.

This idea is: Make it possible to build a 32-bit application in the 64-bit IDE.

An extension to this idea is: be able to build a OSX / Linux executable using the Windows IDE, and all various permutations of that (build Win exe on Linux, etc.). I would be OK with having to download and install some OSX/Linux libraries that would allow this.

View All (16)

The crux of this idea is a very simple premise: Structures should not be allowed to hide code inside their diagrams. Ever. Period. There is no legitimate reason.

The rest is implementation details which are negotiable, unlike the basic premise.

With Autogrow enabled this is not an issue. So it could be as simple as removing the option to turn it off. I would prefer a slight alternative, allow autogrow to determine two different behaviors when an object pushes against a structure boundary: Autogrow = object wins and structure grows. No Autogrow = structure wins and object no longer moves. All structure growth is done by hand in that case.

When upgrading VIs which have hidden code, I suggest a one-time autogrow. Breaking code could be an option ( ), but that would simply force the user to autogrow or cleanup the BD anyway. If there are other errors, a broken run arrow is not a clear, direct indication anyway.

There could be a corollary preventing hidden code in general. I may not agree with them, but I do see that there could be an argument there to allow hidden code in some cases. That battle is being waged elsewhere:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-should-break-VIs-which-have-hidden-code/idi-p/2228268

I see no reason, however, to allow the bounds of a structure diagram to shrink beyond the bounds of its content. Nefarious reasons? yes Legitimate ones? not that I can think of.

I empathize and support this idea as a start:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Visual-indication-that-a-structure-is-hiding-code-beyond-its/idi-p/2242866

But I do not want a visual indication, I want to know by construction that nothing lies beneath.

View All (5)

Size of Array in Probe Watch Window

Current behavior:

When saving a new .lvlib inside a .lvproj the save file dialog brings me to the last saved location which is often a different repo.

Desired behavior:

When saving a new .lvlib inside a .lvproj bring me to the root directory where the .lvproj is saved and not the last saved file location. i.e. implement the same behavior as when saving a VI inside a library or a class. This would solve the issue of VIs accidentally being miss-saved outside of the project folder and then getting lost.

View All (1)

LabVIEW Idea Exchange

Distinctive icon in project explorer for overridden methods

Hide This VI label as default

Add ability to select which version of LabVIEW Runtime is compatible with executable

Changes to sub-components of components of projects shouldn't force change to project file itself

Replace icon of method overrides

Remove the word "Waveform" from the default names of graphs

Wire values on Mouse Hover

"Flattened String To Variant" node should return "rest of the binary string"

Make text search look inside error ring constants

Richer Property Dialogs for Structures

A better way to specify (default) fonts

Display Format Glyph for Timestamps

Restore build speed performance for continuous integration jobs

New Run-Time Window Postion Option: Center on Caller

Jog-wheel (unlimited range knob)

Expose Control "Parts" References as Array of Decorations in Control Property Node

Build 32-bit executable in 64-bit IDE

Structures should not be allowed to hide code in diagrams!

Size of Array in Probe Watch Window

Default to .lvproj folder root when saving new .lvlibs in a project