LabVIEW Idea Exchange

Post an idea

When using the Rearrange Cases window with a Type Specialization Structure, the case list only shows either Declined, Accepted or Ignored. This makes it difficult to know what cases are being reordered. Similar situations occur with a numeric case selector (just a list of numbers) and event cases (dynamic events with the duplicate default wire labels).

This idea is to add the subdiagram label of a case next to each entry in the case list. This would add some context to each item, and make rearranging cases quicker and less error prone.

Alternately (or in addition to the above) would be the ability to preview the contents of the selected case / subdiagram, much like the preview when selecting a dynamic dispatch VI in a class hierarchy. This would be useful for cases with no subdiagram label, or in the case of the type specialization structure, allow visual comparisons of which case should be evaluated in which order.

View All (3)

On a block diagram string constant, there are shortcut menus to change the display style. Currently, we can change the style without making the selector visible. That leads to bugs when later programmers do not realize that the string they are editing is in a different mode. Currently, we have to choose "Visible Items >> Display Style" first, which makes the shortcut menu items useless (because then we just use the now-visible selector ring). In the future, when we change the style through one of the shortcuts, I would prefer that the selector automatically becomes visible.

This is a follow on to this idea. After terminals are wired to growable nodes. Make it easier to move and reorder the terminals. The switcharoo tool exists if there are only two terminals but it is difficult if there are more.

I suggest making it easier with a keyboard/mouse combination or mouse long hold or something like that, to select a terminal. Then let the user drag it to another terminal and drop it. If that terminal is wired swap the selected wire and the one dropped over. If not wired, move the wire connection to the terminal dropped over.

View All (2)

In a simple project, the main entry point into an application is usually easy to find:

However, for more complex projects (particularly those utilising libraries/classes) it may not be obvious where to begin:

Proposal:

LabVIEW should provide a mechanism for tagging one or more VIs such that they are easily accessible to someone unfamiliar with the project.

One possible implementation:

Display tagged items as links at the top-level of the project.
Links would be pinned to the top row
Link names would be editable and need not correspond to the name of the item they link to. (e.g. The link "main" may point to "WidgetTester.lvlib:GUI.lvclass:launcher.vi")
For minimal confusion, developers should be encouraged to name the first link "main" (or similar)
In principle links could point to anything interesting, not just the main VI.
Double-clicking a link should open (or navigate to?) the target item

View All (4)

Hopefully low hanging fruit? I'm constantly checking the error list when working in a VI that's part of a broken class hierarchy to see if the VI itself has errors or if it's just due to a hierarchy error or dependency error. I often repeatedly check it to confirm if the VI I'm currently working in has the errors and could save a bunch of time if something was different about the broken run arrow and I only had to glance at it to confirm I can move elsewhere in my development as expected, or continue to the error list to see what's really broken.

View All (2)

So, i just changed a case from a string input to a boolean input. Ofcourse it gets broken with a red "1" in the case selector. That's logical.

Now i need to select the case selector and write False, then switch to the other and write True ...

Once both cases are correct i can r-click and switch them with a "Make this case False".

Improvement suggestion:

If having a boolean input, the Make this case True/False should be active for all cases always.

Even if you have multiple cases (it'll still be broken and you'll have to clear the extra cases)

I have wasted ~~days~~ weeks of my life tracking down why dependencies are loaded in LabVIEW.

This is because the "Why is this item in Dependencies?" tool isn't particularly useful in larger projects. And it isn't particularly useful because it highlights any file in your project (and not in the dependencies) that is dependent (no matter how indirectly) on the chosen file.

In this example, if I click on "Why is this item in Dependencies?" on library C, I get pointed to a VI in the project (A.a) which has a very indirect dependency on library C.

It would be far more useful to me if I instead only got shown the VIs that directly depended on my dependency (even if they were in dependencies themselves). If I then wanted to follow this up the chain, I could just click on "Why is this item in Dependencies?" again, but on the found item.

When using LabVIEW in combination with other languages, it would be really nice for LabVIEW to be able to read from and write to the stdout and stderr streams. For example, when writing a dll in C that is to be used by LabVIEW, it would be really nice to be able to see the output and error streams from within LabVIEW. As it stands you have to jump through hoops in another IDE or create a log file or some other workaround if you want to see what might have happened inside the dll to cause it to crash.

View All (2)

I think it would be a good idea to enable running code formatter, like Darren's Nattify VI, automatically when saving a VI. Currently, most IDEs have built-in formatting tools which promote a unified, clean code style, and programmers don't have to worry about it because the code is automatically cleaned up before saving. I think a similar function would be a great addition to LabVIEW.

In Visual Studio it is called "Run Code Cleanup profile on Save". You can also configure different profiles (different styles or flavors). This option would be nice to have.

It would be great if it were possible to reduce the amount of time spent cleaning up LabVIEW code while keeping the code in decent visual condition.

View All (5)

VIMs are awesome but when wire inputs are broken they aren't awesome. They'd be awesomer if there was a way to specify that when specific frames of type specialization structures are active, there is a way to get specific strings added to the error info for the caller. Having a way to add custom strings to VIMs would overcome the general "An unsupported data type is wired to this subVI node." error string we're currently given. This can also help differentiate between LabVIEW breaking during type prop for odd (bug) reasons and properly invalid inputs... Do I need to just delete a wire and re-wire the input or do I need to hope the developer provided good VI documentation?

With some additional frames in Type Specialization Structures and maybe something like a subdiagram label but instead it could be a error reporting field at the bottom of a frame, it would be much easier to provide meaningful information back to a developer such as "GUID input only accepts GUID.ctl or a String". Then if the caller breaks with the unsupported data type error for the VIM, error details from the currently active TSSs can be concatenated to the Details string displayed in the Error list dialog. Alternatively, each error message found in TSSs could be separately listed in the Error list.

My 10 second idea:

TSS Error.png

Resulting in the Error list perhaps showing it as either an error or concatenated into the Details:

TSS Error list.png

View All (1)

LabVIEW Idea Exchange

Show subdiagram label and/or preview in Rearrange Cases window

Changing display style on string constants should make the style selector visible

Easier Reordering of Terminals

LabVIEW Find Search Scope - Add user.lib

Outputs terminals on diagram disable structure should not default to "Use Default if Unwired"

Project should support links (like bookmarks) to main VI

Show a different broken arrow when the VI doesn't have errors itself.

Do not apply VI Properties "Run Time Behavior" until the vi is running!

Allow Wire Labels to Dictate Name Inheritance in Bundles

"Find Callers" for Class Data

Boolean case improvement

Increase Icon Resolution

Change class <-> interface

"Why is this item in Dependencies" should only show items that are directly dependent on it

LabVIEW access to stdout and stderr

Cluster Support for "Add Array Elements"

Run Code Cleanup profile (Nattify VI) on Save

Type Specialization Structure Error Message

Add Right Click Menu option to "Find Objects at Edge" for Auto Grow Structures

Estimate and show Time Remaining during LabVIEW Installs