Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
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!
Working with class method VIs becomes easily confusing if you need to use VIs from several classes that are inherited from each other. Every class adds or overwrites VIs from one of the ancestor classes but usually you don't know which one. And if you're just user and not developer of this class structure you're usually also not interested in the exact inheritance hierarchy.
Look at the picture: As programmer of the application "main.vi" I'm just interested in Class 3 but I also need to know the internals of Class 1 and Class 2 whereby Class 1 is not even in my project. So I can't see that there are also other cool methods within Class 1 and to get methods from Class 2 I also have to search inside of it and compare against Class 3.
As reference: This is the content of Class 1
What I suggest and expect is the following:
=> The class tree shows all available methods within each single class!
bright colors: Methods that are defined in this class; pale colors: inherited methods
When you right-click on a connector pane terminal, a context menu pops up -- but there isn't a good indication of which terminal you've clicked on:
You could assume that selected terminal is at the top-left corner of the context menu, but (due to a bug, I'm assuming), the actually selected terminal is a few pixels down and to the right of where you clicked.
What if the terminal you right-clicked on got highlighted while the context menu was shown? This would provide visual feedback of the selected terminal, giving you confidence that you clicked on the terminal you thought you clicked on (and avoid mistakes of configuring the wrong terminal). I can't even begin to count the number of times I've set the wrong terminal to "recommended" or disconnected a different terminal than expected. Could look something like this:
(which just piggy-backs on the appearance when you're wiring up a terminal:
Bonus points if the bug gets addressed where clicks are actually a few pixels off.
Given the properties dialog box isn't resizable, and there's nothing under the table (apart from one tick box), could you make the items table longer? It's really annoying when there are a few extra values that can't be seen because the table is too small.
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:
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.
but that one was more generic to get the a subpanel reference from within the subpanel.
(My specific use-case is to create a fancy menu popup relative to the clicked item within the subpanel- basically, I need screen coordinates of the "thing" inside the subpanel, which I cannot get without coupling the subpanel VI to the main VI by providing an upstream VI reference, which I don't want to do.)
LabVIEW 2020 allows you to remove the event property nodes shown here:
It's a nice feature because these nodes are often not used and can get in the way. However -- the process for removing them is a bit tedious: you have to either remove them all individually or size the cluster down to one and then remove through a menu. I find that I rarely use this because, well, it just takes too long.
However...if you could just click on the node (it's already selectable) and then click the "delete" button on your keyboard, this process would be near-instantaneous, and I know I'd be much more likely to use it.
There are two things that bother me about the index array. I think these changes would be useful to nearly all LabVIEW users.
The default value is not optional (for integers always zero, a very useful value) There should be a way to set the desired value if the index is out of bounds.
There should be a way to get rather the index is out of bounds from this primitive since this has to be check anyhow to know whether to use the default value. should look something like this:
The lack of these items usually proves to generate code that looks much uglier than necessary.
Although I do not know the internal workings of this primitive it would be hard for me to believe that this would have much of a performance impact. Also, bound checking arrays is necessary for many algorithms, why do it twice?
In LabVIEW we can specify <topvi> as a VI search path when VIs can't be found.
I would propose adding <project> as an option (perhaps with a subfolder by default). This would allow for new reuse patterns based on keeping libraries in the project. I expect this would make tools like GPM much easier to develop as well.
It could be a first step to something like node_modules in NPM or virtual environments in Python.
Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.
I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either.
Right-clicking on a VI in a project and selecting "Find -> Callers" doesn't list any .lvtest files which call the VI in question. I think there should be a relatively easy way to find which unit tests call the VI. I use Find -> Callers when I'm refactoring, and want to know what code might be impacted by a change. It'd be nice to quickly find the unit tests which also call the VI.
Option 1) Have Find -> Callers include .lvtest files in the results alongside calling VIs.
I have a 3D set of data, to which I fit a plane, and then from that plane fit a bounding box which should contain 99% of all data.
I would really like to plot both a scatter of the source data, and the surface within the same plot. Ideally the box would have transparency, but even lacking transparency it would be very convenient in visually confirming the quality of the fit.
A big project can take more than 10 minutes to load, especially on an older computer. If subVIs are missing, the Ignore Item and Ignore All buttons become available when the first VI is missing. This can happen anytime during the loading and the process stops until the browse box is canceled and then the Ignore All button is pressed.
It would be better if the Ignore All button was always available where it can be clicked at the beginning to insure the project is loaded in the expected time.