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!
If I have a Control labelled '%s In', I would like to be able to right click on it and select Create Indicator, resulting in a terminal label of '%s Out'. Likewise, if I have an Indicator labelled '% Out', I would like to select Create Control and automatically label it '%s In'.
Simple enough, but one of those tiny little tweaks that would save me a tiny fraction of effort every time I do it 🙂
At the moment, if I want to review my search results, I'm required to double click each item. This opens the diagram (usually) and the front panel. I then have to close them, or I might end up with dozens of open windows.
Of course I could use CTRL+G, but I'd still need to clean up the opened windows.
Another slowdown is that the highlighted item can popup anywhere on my screen(s). This "gaze time" adds up if you need to browse through dozens of results.
It would save me tons of time if the search results window had a preview of the result:
The found item should be in the center, preferably highlighted in some way.
It would allow me to give the listbox key focus, and use up\down to browse through all items very quickly, without any need to clean up!
Sometimes, you may want to delete files that are read-only. The Delete primitive outputs an error (Error 😎 when you try to delete a File that's set to read-only. One then has to change the file permissions to writable and retry deleting it. That's a pain. What's even more painful is when you try to delete a folder, recursively, with the Delete function -- passing it a folder path and setting Recursive to TRUE. In this case, if even a single file inside the folder is set to read-only, then the recursive delete will fail -- now, the developer has to do their own recursion to find the file that's read-only, mark it as writeable and then delete it. OK, convinced this is a pain? Here's the solution...
Add an input called "Ignore Read-Only" to the "Delete" function that will do all this form me.
The OpenG Delete Recursive VI (in the OpenG File Library) has such a feature already. I was excited when LabVIEW implemented a recursive delete and I started using it all over the place (it's nice to write code that doesn't depend on external libraries, when possible) and then... I got bit by this limitation in some random corner cases where files had gotten marked as read-only.
Breakpoints are great for debugging. But...I've never wanted to share them with another developer, and I've never liked it when they add the dirty dot to code that I haven't otherwise changed. This can lead to unnecessary code changes which can add hassle to source control, and it can lead to other developers unintentionally inheriting your debugging breakpoints.
How about an option to manage breakpoints separately from source code, perhaps similar to how compiled code is handled?
When creating a new Source Distribution to run on an RT system. It makes no sense that the "Exclude vi.lib VIs" option is checked by default. The VI will not run and cannot be launched asynchronously which is the whole point of a source distribution on an RT system.
The "New Source Distribution" wizard that creates it with default properties should look at the context it is being created and pick appropriate options. This is supposed to be a smart IDE.
This idea was posted years ago and declined for lack of interest (it got 6 out of 7 necessary, but I would have been the 7th!). I would like to bring it back, I would like my application to have access to it's own version number. In fact you can open the project programatically and see some build properties but not that one. I can then grab the version from the build properties and set the default values on my FPGA code before compiling.
I was trying to make a pre-build VI that would look at the build properties and copy the version data into a control. Can't be done. I find this very useful to make sure that my RT system and my FPGA code have the correct versions.
Same as with an about box, or version checking for compatibility.
The previous thread suggested a routine in the FileVersion.llb but that seems to only be available in a single platform. Not useful for RT linux or Mac. The version is not available until the executable is built which does not work for FPGA.
At the moment my only recourse is to hand copy the version from the build properties and then set those as a series of 4 integers on the FP. (Then select them all and set their values to default, hence the other suggestion about right click)
Since LabVIEW 2017, the default build specification check the option "Allow future versions of the LabVIEW Runtime to run this application".
I don't undertstand why it is checked by default when you read the help that said "Disabling this option prevents any changes to the performance profiles and helps you avoid unexpected problems resulting from compiler upgrades."
Because NI and me doesn't know the future, NI will never garanty that your application will run with all the future LV Runtime. I know it well because I'm facing this issue with le LV RT 2020 that breaks the execution of different application that I have buid in 2017 SP1.
The behavior is a little strange too, because, even if you have the run-time use to build the application on your computer, the application will use the highest one present one the computer.
This options can be very usefull, and I appreciate it, but maybe we need to have more control on it. So my idea is to give to the user the ability to list supported or unsupported LabVIEW Runtime.
This will help us managing future LV Runtime without having to recompile the application which seems to be the goal of this option.
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's a lot you can do with LabVIEW to improve the appearance of the UI. The community has really helped move the LabVIEW UI frontier forward with many wonderful UI palettes and tools to improve UI creation and customization. One key limitation to all of this though is that LabVIEW controls are comprised of parts that are NOT programmatically accessible.
This is a large drawback since it prevents developers from creating dynamic UIs. For example, you cannot really add a good "Dark Mode" feature without designing specifically for dark mode because Frames and other control components are not customizable at runtime.
LabVIEW could use a feature that's commonly used in C++, the "final" specifier for a class override method. This would allow a child class to override a method from a parent class (or interface) and then prevent child classes of itself from overriding. Currently, with large inheritance structures, it becomes difficult for developers to create child classes since so many of the methods can be inherited from. The final specifier would allow you to create intermediate classes that define certain override functionality that does not need to be further overwritten and only pass on the ability to override methods that are important to child classes.
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.
When you select several items the "right-click" functionality is available only for common operations. One of those common operations for several controls and indicators would be to set the current value to default or set the default value to the current value. Both of these are available from the menu option for multiple selections.
However, this option is removed from the right click option when multiple items are selected. Why? Simple UI configuration.
If I am on Mac or Linux and I try to open a VI that calls a DLL inside of a Disabled Structure, then LabVIEW searches for the missing DLL.
This is really a waste of time and effort, since it will never find or be able to load the DLL on Mac.
LabVEIW should be smart enough to know that it's not going to file a *.dll (Windows dynamic linked library) or a *.so (Linux shared object) on a Mac -- Mac uses .framework as it's shared library files.
So, I would extend this a little further and say that LabVIEW should only search for shared libraries of the type for that platform (.framework on Mac, .dll on Windows, .so on Linux).
Note: if a Call Library Function is configured for cross-platform (meaning it's configured for with a "*" file extension like mylibrary.* so that it will find the correct extension on the target platform) then go ahead and search for it.