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!
I inherited lots of VIs with complicated terminal connectors. It is a challenge to determine which terminal is associated with a given control.
Why not highlight the associated terminal when a front panel control has been selected?
In other words, currently when I select a terminal, the corresponding control is highlighted. I'm proposing that it should also work the other way -- when I select a control, the corresponding terminal gets highlighted.
I have just figured out a workaround, but it's clumsy. I can temporarily delete the control, observe which terminal goes white, and then immediately restore it with Control Z. But my proposed solution would be cleaner.
Have you ever wanted to place a probe on a loop iteration counter? I can't tell you how many VIs I have with a wire from the iteration counter to the loop boundary just so I can put a probe there (Maybe a pop up iter. count would suffice). Or probe an output terminal on a VI that is not wired. I know you can open the VI and put a probe on the wire but..
There are probably more cases.
Minor issue, but since we have a chance to ask..has been bugging me for about 20 years now.
I suggest that radix is always visible when the numeric display format is other than decimal. Is this number decimal for instance?:
Well, it was hex:
... -> ...
Basically you'd know that if there isn't a radix visible, then the number is decimal. It should still be possible to show radix for decimal numbers as well. This should be the case for both constants and controls/indicators.
Just one of those little things that would enforce a minimum of documentation.
I sometimes need to create Front Panels that are to be navigated by keyboard alone, which makes the tabbing order quite important. At this stage, I need to ensure my error cluster controls don't get included in the tabbing order list. Given my error cluster controls for any VI that shows its front panel will be moved out of the visible area, I need to ensure the operator cannot tab to them. Therefore, I would like to see error in clusters have their default "Skip this control when tabbing?" property set to True.
I don't think a change to the default property would cause any complications?
I have noticed in some places in the LabVIEW IDE that the selected attribute is not properly highlighted. A perfect example is Cursor Attributes on a Waveform Graph:
The currently selected Point Style and Cursor Style Attributes are highlighted with a blue box, but the Line Style and Line Width are not highlighted with the current values. This is important to know, because it is difficult to tell the difference in line widths, and could even be impossible if the cursor is off the screen.
I can only find these two places right now that the current selection is not highlighted, but once I find more I'll post in the comments.
When designing larger user interfaces often times my event structure ends up with many cases sorted in no real order. Commonly there are multiple controls that trigger the same event case. It is cumbersome to try and find the particular event case where a control is handled.
What I would like to see is a Find -> Event in the shortcut menu for a control. We can currently search for the front panel control, local variables and property nodes if used. It seems logical that events should be included in that list as well.
When creating complex UIs with a lot of controls on the front panel, it is difficult to find the control we're trying to associate an event with from the Edit Events dialog, as controls are not sorted alphabetically. It seems they are sorted in the order we create them. Sorting them alphabetically would improve our efficiency as it takes more and more time to find the control as rthe UI grows.
It would be nice to have bookmarks (possibly based within the project) so that you could quickly jump to certain areas of your code that has to be modified or reviewed frequently. Obviously, things like state machines are self documenting, but it would still be great if you could quick jump to certain areas. Being project based, you could also jump to any bookmark in a subvi.
You can open a type definition by right-clicking a diagram terminal, constan, or front panel control, but it is not possible to get to a type def file just from a wire. There are a lot of times where I'm working on a diagram that uses a type definition that is only exposed as a wire. Right now, the process of getting to the type def is to create a temporary constant from the wire, then right click the constant. It would be nice to make it easier to get to the type def. And of course, I would like to have the same functionality for LabVIEW classes.
Currently, the only native way to display a JPEG in memory on a 2D picture control in LabVIEW is to
save to disk
read from disk
This is not only silly, but slow: on a reasonable fast machine with an SSD, this takes almost a second!
A simple request: A VI that can go straight from JPEG binary data (other formats would be nice) to a 2D picture control. This is very useful for applications that download images from a server - a pretty common thing to do.
With 6 or 8 input/output patterns it is extremely difficult to see difference between particular I/O. This is even more problematic you use for example INT32`s or other data types that have dark color as default.
One gets few pixels of dark blue with black border around it to make things even more difficult.
- Make an Assigning Terminals mode where the icon with terminals gets enlarged eg. x4 and where all terminals are clearly visible.
- Do not add more black borders, just stick to the data type color.
- Add clear indication which controls and indicators have already their terminals assigned (general information). User by clicking can see which one is assigned to what terminal (as it is now)
When selecting properties from the Y Scale, I would expect to get the properties window opened for that axis. But no, you get the properties for the x-axis. But I distinctly selected the properties from within the Y Scale. See image below.
My suggestion is to open the properties window to the axis where the selection was made from.
I'd really like to be able to select the entire top-level cluster in an event structure, if event data is a cluster:
I know this have been brought up in numerous forums over the years, but I feel it's being ignored somewhat by NI? It usually gathers quite a few positive acknowledgements from other users, but I think it's about three years since it's been brought up in the idea exchange. It seems so easy to implement and would greatly simplify many event structures. So forgive me for duplicating something from countless other places, but I think it deserves a second (or ninth or whatever) glance