LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (1)

I like to collapse long string and path constants to consolidate diagrams. Showing the string or path value in the tip strip is useful but tedious to update.

I suggest an appearance property that would automatically display the current value in a tip strip for string and path constants.

This property would be most useful if the Block Diagram Options page was also modified to allow a global setting.

View All (3)

View All (5)

Searched briefly but couldn't find any ideas about this.

I know we have the ability #via_ignore comments to ignore specific tests for a specific VI, but I am looking at a different use case.

Here's the use case, I use DQMH. When you create a new DQMH module there is a lot of plumbing code that comes with it. It's standard stuff. Very rarely do I have to open or edit it. Much of it is scripting generated. It often fails tests but I don't care. In addition to failing, it takes up test time, which slows my feedback loop. I would a way to signal to VI analyzer to skip these files. I know I can use the VIAN API to limit the files it checks, but I was thinking there had to be a better way.

Implementation Ideas - I had 2 main ideas

- Regex matching on VI names - with the regex pulled out of a text file somewhere ala gitignore. Many of the DQMH generated VIs have standard names, so that is easy. When generating events, they don't but you could easily add a prefix/suffix or something that the regex would pick up.

- Using the Tag API to tag the VI. I like this because the scripting can just apply the tag or apply it to the template the scripter uses. Downside is: kind of hidden from the user and perhaps if I decide to make some edits to this VI I may want VIAN to stop ignoring it and it's not immediately obvious how to do that.

Note:

I picked the Execution and Performance Label because it didn't seem to fit any of the labels easily. If this is the wrong label and you are an admin, please relabel it.

View All (2)

View All (6)

Navigating long lists in LabVIEW can get painful, e.g. for producer consumer design patterns and message handlers.

This idea is to add submenu parsing for dot notation items.

Now your case structure can do this:

I don't think it will effect ranges in the case selector as it requires two dots... e.g. "Init.Step1".."Init.Step4"

Credit: This thread for inspiration: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Case-structure-easier-selection-for-structures-with-a-large/idc-p/4192417?profile.language=en#M43910

Suggestions required on how to handle a list in this situation where its a lot of numbered messages.

Also I just learned from a colleague that by grouping controls carefully (& some caveats) with the dot notation on FPGA it allows for a submenu. (And clusters on a FPGA can take up a lot of gates). So LabVIEW already has some code for this feature. Can it be leveraged? See below:

https://forums.ni.com/t5/LabVIEW/Group-FPGA-Controls-With-Dot-Naming/td-p/2767678?profile.language=e...

This post generated this idea which is the same problem in the FPGA space... grouping long lists to make them easier to use.

https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Better-FPGA-FP-Control-Selection/idi-p/3074718

View All (5)

View All (2)

Color Picker Event On Mouse Movement

If I drop down a color picker control, I can get an event on it for when a new color is selected by using the value change event. But what if I want to know what color the user has their mouse over, before clicking on it? Many of NI's controls change color as you select a new color. The Graph plots for instance will update as you move the mouse around.

This idea is to allow color picking controls to have a new user event, which is Mouse Over Color which gets generated when the user mouses over a new color. This way we can make applications that change the color of some UI element before the user picks the new color like NI does.

This can be accomplished today by recreating the color picking functionality in a new VI. Here is one example posted that allows you to pick a color. Using this someone could generate a User Event, or post to a global as the new color selection is being made.

Permanent Knight License

In LabVIEW you need to know the number of sub matches at edit time and cannot handle arbitrary regular expressions. It would be nice if there was a regex function that returned sub matches in an array which can be handled much more abstractly than a pre-sized xnode.

C++, the regex utilities return a container-like class https://www.cplusplus.com/reference/regex/match_results/

PHP an array of matches is returned https://www.php.net/manual/en/function.preg-match.php

JavaScript returns an array of matches https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/match

View All (4)

vi properties window name

I'm developing code, and like most people I know, I have multiple VI's open at once.

If I then go and open the VI properties dialog, I lose track of what VI the properties are for, especially if I get an interruption. I know I can just close the properties window and open it again for whichever VI I wanted (or go to the parent category to see the name), but this could be solved by simply adding the name of the VI to the window title of the Properties dialog.

like this:

View All (2)

Currently, for waveform/XY plots/graphs, the legend, graph palette, cursor window, etc are all "coupled" with the graph itself from a "graphical" perspective.

This means that all of these "addons" must be attached to the graph, and you can't put them in a different part of the panel. Screen resizing thus tends to screw things up, especially if your plot names can be defined by the user.

I'd like to decouple these somehow.

For example, I'd like to be able to put my legend and zoom tools in separate panes separated by splitter bars, or even in a right-click style menu (like a subpanel popping up). This feature would let you use automatic resizing on the plot itself and keep the legend separate.

You could theoretically program your own version of this, but:

-Recreating the legend functionality (line size/width/etc) would be a large undertaking, especially since there isn't a native Datagrid type control that could display a checkbox, string, and small image.

-I don't know of a way to get at the built-in zoom/pan tools programmatically (yes, you could create your own, but it's a big PITA)

-It wouldn't work at edit time, like the current features do, unless you baked all of it into an Xcontrol

Basically yes, you COULD get a lot of this done yourself... but it'd be nice to just use the tools NI already made, which work great. I don't want to reinvent the wheel just for some graphical convenience.

Add Control Anchors to Labview

.net and many other languages have an intuitive and simple way to allow you to define how a window behaves when you resize it: anchors. Anchors allow you to define the distance between an edge of a child control and the edge of a parent control regardless of the size of the window. The size of the control itself stays constent unless it violates the rules of the defined anchors in which case it changes sizes to meet those rules. For example a front panel with the following anchors:

Would be resized into:

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)

Key focus Event

View All (5)

There is a path type selector (Valid Path/Not a Path) on all the path controls. This is useful on "data" type controls (subVIs) where you may wish to test input values, but rarely useful (may even be confusing) on path controls used on end-user facing front panels. They make no sense at all on indicators. These selectors are most prominent on the NXG style controls:

NXG Style Path.png

Here's an idea to be able to hide these buttons, just like we can hide the browse button. Perhaps Show/Hide/Hide at runtime options, but at least Show/Hide options.

View All (5)

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)

Suppose a front panel contains the three elements seen below, with the first one being selected.

1 (edited).png

In the situation above currently pressing Tab does nothing. It would be useful if, instead, pressing Tab would cycle the element selection to the next element in the tabbing order, as seen below.

2 (edited).png

If Tab was pressed again, it would cycle to the next element in the tabbing order, as seen below. And so on.

3 (edited).png

Notes

This idea would speed up development by enabling us to cycle through element selection without using the mouse.
When used in conjunction with the F2 idea, this would enable us to use Tab + F2 combinations to quickly cycle through elements and rename their labels and/or captions.
This idea could be extended to terminals on the block diagram. Suppose a terminal is selected on the block diagram, pressing tab would navigate to another terminal on the block diagram.
I'm aware that currently it is possible to use Tab or Shift+Tab to cycle between elements forwards or backwards when the VI is in Run Mode (Ctrl + M). While that is useful, this idea asks for more.

Thanks!

View All (3)

The idea is simple: if the label ends in a number (i.e. consecutive string of numeric characters), increment that number:

It seems like it only works if there is a space character. If there is a good reason for doing it that way, help me understand what it is.

I linked some similar ideas below. I like these discussions for the most part, but they tend to have broader scopes than what I'm suggesting.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-er-automatic-label-names-on-copy/idi-p/1873663

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Auto-increment-number-in-middle-of-control-name/idi-p/977710

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Don-t-skip-quot-1-quot-during-automatic-naming-of-copies/idi-p/977300#A2089

View All (2)

Let's say I have a ring control filled with lots of of items, but I decide that it would be better for the user if he could see all the options without having to pull down the ring. I right-click on the ring control, choose replace and select a Listbox. Now I have an empty listbox though, and I have to recreate the list. Most of the times when I do this I want the items I had in the ring control to transfer to the new control, like this:

replace with content carried over.png

The transfer of items should work both ways, and apply to similar replacements, like a change from ring to enum e.g.

It would be nice to have a way to choose whether to keep the items or not of course (key control while doing the replacement or a dialog asking if you want to keep the items), instead of having to delete the items afterwards if you did not want them, but I am not sure it would be needed that often. I would be perfectly happy for the default to just keep the items.

PS. Writing a quick drop shortcut plugin is one existing way of getting this functionality without having to wait for NI to implement it in the IDE...Perhaps someone has already done that (?). This request is for it to become (or be a part of) the default behavior though.

LabVIEW Idea Exchange

Webservice Swagger/OpenAPI document generation

Automatically Display Value in Tip Strip for String and Path Constants

Add licensing and activation tools for packed project libraries (PPLs)

VI Analyzer Ignore Certain VIs Completely

String control/indicator/constant with line number display.

Dot Notation for Auto Submenus for Easier Navigation of Long Lists

Boolean Array to Number Right Click Menu

Color Picker Event On Mouse Movement

Permanent Knight License

Provide regex functions with match outputs as an array

vi properties window name

Decouple plot legend/tools/etc from the plot graphic itself

Add Control Anchors to Labview

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

Key focus Event

Allow hide of path type selector on path controls

Run Code Cleanup profile (Nattify VI) on Save

Tabbing between front panel elements should be possible at Edit Time

Increment label ending in numeral when copying control

Keep items when replacing ring (or enum) with listbox (and vice versa)