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!
When building applications that use many different toolkits and classes, my build times can skyrocket. It's frustrating that while i'm waiting for my application to be built LabVIEW is useless for development. This is especially aggravating when I find a bug that takes 20 seconds to fix, but then building the application takes another 20 min. To address this issue I propose that there be an option to launch the build process in a separate process from the IDE so that I can continue working with my code in the meantime. This could mirror the FPGA compilation process where it used to block development but now is separated out.
Why optional though? For smaller applications the build process is very quick so if you can live with it I wouldn't want to always introduce the extra overhead that I assume would be necessary to lauch the build as a separate process.
When building an installer to let an application run on another computer one should select all the installers of products used in his porgram. This can be really tricky, especially to new users, that don't know if a VI was included in package A or B or if it's already included in the standrad runtime.
Therefore it should be possible to hit a button, that parses through the Application and determines which packages are used.
I though of writing something like this myself, but I can't be bothered
You'd just have to parse the Project, check all the VI names and relate it to a table that contains information, about where a VI comes from.
The issue of a modal window being left open during debugging, only to jump to the front when the top level vi is run, has been an issue in LabVIEW for as long as I can remember. I am certian that every developer at one time or another experiences this behavior. There are several work arounds to this issue such as "the old 3 fingered salute" (CTRL+ALT+DEL) and kill LabVIEW, programmatically setting the window modality, external VI task managers, etc... however all of them are workarounds to deal with the issue.
The crux of the problem is that any front panel specified as modal immediately becomes modal as soon as the VI is reserved for execution. This proposal would establish additional option to the VI properties dialog (Modal when Executing). Which would only initiate the modal property of the window when the VI was actually executing.
There have been several similar ideas related to dealing with window modality (see below) however I believe this implementation is different than anything I was able to turn up in a search.
When doing UI work, it can be quite frustrating rewiring hidden controls to the connector pane. You have to go to the block diagram -> Show Control -> go to front panel and wire it up then hide your control again.
My suggestion is that when you select the Wiring Tool on the front panel or click on the connector pane (to wire up a terminal) all the hidden controls would become partially visible and become connectable to the connector pane.
I often find when programming with LabVIEW that I don't have room on my block diagram for free label documentation. I find it hard enough trying to keep clean and tidy code and even harder document it well. Free labels take up lots of room and I end up not writing good documentation because I don't have room for it.
My solution to this problem is a Documentation Node where you can write comments in a free label, minimize it and use context help to read it in the future.
In the string constant you are able to make a scrollbar visible but this is still inconvenient when only see 2 lines of your whole string when you have a string constant of 50 lines or so... and you 9 out 10 times you don't want to create a bigger field because it messes with your diagram.
Therefore a small popup with a only a large textfield would grately simplify things.
Direct to PDF reporting is an extremely important feature to provide customers. It cannot be relied upon that the customer has MS Word or the like installed.
There are a couple of LV PDF toolkits supplied by developers. However, the problems with these include that they are (a) not updated or well-supported (b) buggy (c) have out-dated dependencies such as .Net 2.0 (d) restrictive licencing for deployment.
Good reporting tools are essential and NI should develop and support a direct to PDF toolkit.
I work with customers who use multiple versions of LabVIEW. Being able to run two (or more) different versions of LabVIEW concurrently is a boon to my development and productivity. However, identifying which version I am looking at or have open can be difficult.
Can YOU tell which versions I have on the taskbar?
To remedy this, I suggest a version badge be added to the taskbar icon for LabVIEW. This will facilitate quick identification of LabVIEW versions.