LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Do you have an idea for LabVIEW NXG?


Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!

Post an idea

Add a new button to the search results dialog called "Set Aside" so I can have multiple search results open at the same time.  Put it near the bottom just below the search results.  When you click it, it changes the title of the window to "Search Results - Set Aside 1".  If you click "Set Aside" again when #1 is open, it will open "Search Results - Set Aside 2" ... and so on.  This way you can have several different search results open simultaneously.  I love the check mark feature in the search results, but it resets every time the search windows is closed or overwritten by a new search.  Thus I lose my place if I want to make sure to check every instance of something but need to search again while looking at one item.

  • UI & Usability

One of the most over-looked LabVIEW VI Properties, mentioned in all of the "Good LabVIEW Coding Practices", is the one called "Documentation", where you describe what the VI does, and its Inputs and Outputs (at a minimum).  [NI Examples are certainly guilty of this].

 

I've been trying (and mostly succeeding) to ensure that every VI I write has such Documentation.  Sometimes I make a mis-type, highlight "bad" parts, and hit the "Delete" (or backspace), then say "Oops, erased too much, let's undo that with ^Z".  Except there is no Undo, or at least it isn't bound to ^Z here.

 

I can find no other place in LabVIEW that doesn't allow ^Z to replace deleted text.  It works in String Constants, in Labels (whether Free Labels or names for Controls/Indicators), and other places.

 

To encourage LabVIEW Developers to use the Documentation property, can you please allow us to "undo a boo-boo" with ^Z?

 

Bob "Imperfect" Schor

  • UI & Usability

I am not happy when I inherit legacy code where VIs have inconsistent alignment grid options, as shown in the image below.Inconsistent Alignment Grids.jpg

 

My team has coding standards we follow, and those standards include alignment grid options. It is labor-intensive to change alignment grid options on legacy VIs because you have to do it by hand, and clicks quickly add up. I wish I could automate such changes.

 

I’d like to see a few new properties to expose settings available in the editor, as shown below.Alignment Grid Property Nodes.jpg

These properties need to support both read and write.

  • UI & Usability

The proposal consists in being able to format the content of a string control, to allow to read more easily: INI, XML, HTML, ...

 

Code Formatter.PNG

 

Regards.

  • UI & Usability

CE2E8EE4-75FC-4855-BE7B-2A9C88698EE2.png

 

  • UI & Usability

User Event Refnum.PNG

 

Create User Event function

Output of Create User Event function should be name of the input instead of "user event out"

This will save time to rename each output indicator as input. 

  • UI & Usability

Title basically says it all but I'll elaborate.  With increasing monitor resolution, a 16x16 glyph on a listbox doesn't work very well.  On a 4K monitor this is awful tiny.  This idea is to support larger glyphs in Listboxes, Multi-column Listboxes, and Trees.  Glyphs are used in several places but on favorite of mine is to have item selection with checkboxes, example here.  Allowing for these glyphs to grow with the row height would make them appear more cohesive.  There is a thread discussing this topic, and a work around involving an array of picture rings that is placed over the listbox control.  Here is a demo from that thread:

 

Untitled.png

This work around is fine for simple things but doesn't scale well, and doesn't support trees easily.  I for instance want to have two trees, where a user can drag and drop from one to the other with the larger glyphs coming along with the drop.  Having to handle where the user dropped, and then dynamically building the glyphs to overlay on top of the tree, with indentation, and hiding when a tree's leaf is closed is a major pain.  Please NI add a feature allowing for larger glyphs, and I would be so happy.

  • UI & Usability

When I want to find a specific item via the "Find" dialog, I sometimes want to limit the search to a specific loop or portion of my code.

 

I think it would be useful to be able to specify where to search on a more granular level than per VI, similarly to how the scripting VIs work for traversing objects.

  • UI & Usability

Wouldn't it be great if you could list only the recent files opened while in a particular project? I often bounce from one project to another, closing the projects in between.  Thus, I often would like to be able to view only the file recently opened from within a

the project I am working on. Adding a "Recent Files (by project)" to the Getting Started window would be valuable as well.

 

2018-12-07 view recent files by project.png

 

  • UI & Usability

Add an additional search scope in the scope dialog.  New scope will be <entire project>.  Right now the widest search scope <All VI's in Application Instance> will not reach VI's that are called by reference, but still in the project.  I have a few co-workers which are "call by reference" happy and it's a pain to track them down manually.

 

 

 

  • UI & Usability

 

Change the Path Type function output from a signed 16-bit integer to a text ring or enum to aid immediate readability of code and save having to look at the help file:

 

LabVIEW_2018-11-05_09-16-13.pngThe Path Type function returns a signed 16-bit integer indicating the following 3 types of paths.

0: Absolute path

1: Relative path

2: <Not A Path>

 

LabVIEW_2018-11-05_09-26-34.pngUnhelpful context help.

 

Text ring would have the least impact on existing primatives: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Path-Type-Function-needs-another-return-for-an-empty-...

  • UI & Usability

The error ring is a great and simple tool to define errors, especially when selecting "Custom Error Message" and supplying parameters from outside of the error ring.

 

errorring.png

 

The fact that the text search doesn't look inside the error ring makes it hard to find hard-coded error codes. 

 

Idea: I would love to see the search in LabVIEW also find strings inside error rings. 

 

PS: This idea (or inspiration for it) comes from Stefan Lemmens.

  • UI & Usability

If creating a reference to a .Net control you will observe that is reference type of ActiveXContainer is created which is sometimes confusing at a first sight.

 Container.JPG

Please introduce a .NetContainer (at least cosmetically at block diagram) for a better overview. If you are doing so, you could change as well the color of the ActiveX container with respect to the .Net container on the block diagram. If you have to change the programming interface, it would be much easier to spot where you have to do so.

  • UI & Usability

I just ran into a situation today where I had a case structure with approximately 64 frames in it, 48 of which I wanted to remove.

 

The method of right-click the selector, select "Remove Case" (This step is right beside the "Insert Case" which is frustrating), repeat 48 times while the mouse is wandering all over the screen between the case selector and the menu selection..... cue carpal tunnel problems.

 

I really wished I could just either use the "delete" and "insert" buttons to mimic the appropriate menu selections

-OR-

Be able to select multiple cases from the "Rearrange cases" window and select "Delete".

  • UI & Usability

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.

  • UI & Usability

It would be nice if the Error Ring would accept enums.

Enum in Error Ring.PNG

So the Error Ring does not accept an enum (A). Format Into String does (B). So now we need the extra step of putting a Format Into String before the Error Ring (C).

 

This would be more convenient in for instance state machines (D) or functional globals with a function enum.

 

While on it %s on FIS also accepts Booleans. Nice to have the error ring accept them as well, just for completeness.

  • UI & Usability

Currently to AutoScale an axis once, you need to set the ScaleFitX/Y property to 1. However this is really just like calling a method since the value of the ScaleFit property remains whatever it was previously. As a result, I find this mechanism unintuitive and would prefer to use the invoke node to call a suitable method named ScaleFitX/Y since it is an operation that just happens at a moment in time rather than changing a property.

Autoscale Axis 1.pngCurrent Method: Property NodeAutoscale Axis 2.pngProposed Idea: Invoke Node

  • UI & Usability

The idea is to know the result of the tunnel mode condition, in this case, it is to know if any element has been indexed.

 

whileconditional.png

 

This publication is motivated from the following discussion: Tunnel Mode Conditional .... output condition (by @ouadji)

 

Regards.

  • UI & Usability

Error in terminals that are ignored/passed through by the VI without preventing normal execution should be marked differently in my opinion.

I've lost count of the times where I have to keep reading through the help files to check a function's error in behavior.

Examples: Release Semaphore, Close reference, Release Notifier

 

Then there're the functions that I have created that exhibit the same behaviour. People reading won't be able to tell at a glance if the error prevents execution when called from another function. As a quick fix I label the terminal 'error in (pass through)' or 'error in (ignored)', but it's not ideal.

 

Bonus points if this can be marked as such during development and the behaviour enforced/checked at compile time similar to the following (I know it will be difficult to reliably implement, so maybe warn instead):LabVIEW_2018-08-17_09-49-36.png

 

  • UI & Usability

Originally suggested by RavensFan.

 

LabVIEW scripting makes it possible to automate repetitive tasks in LabVIEW, but it is often difficult to find the properties and invoke nodes to accomplish the task. It would be great to have a recording feature that watches what you do in LabVIEW, and then generates the corresponding code for it. I'm sure the engineers at NI could design it much better than any more specific ideas I could throw out, so I will leave the rest up to them. 

  • UI & Usability