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!
Everytime I build an executable I have to provide a custom INI file just to disable the localized decimal point. Please add a checkbox for this important setting to the application builder, e.g. on the "Advanced" page.
For non-integer increments, the data entry currently accumulates binary errrors due to the limits if the DBL representation, so e.g. sometimes the upper limit cannot be reached using the increment button several times, but only when entering the upper limit directly.
This comes up at regular intervals, e.g. here. In one fo these discussions, I long ago suggested to make it into an idea. It seems this has not happened, so here it is!
This limitation needs to be handled with some internal code, e.g. to coerce the value to the nearest decimal fraction based on the least significant digit of the increment value whenever the up/down buttons are used. ... or something similar.
This one may have been overlooked before. Often experienced users will enable FP gridlines to help with object placement.
Tools>>Options--Front Panel Grid section offers some very useful usability enhancements. But, when you move away from the default settings you miss one thing. The Gridlines are the same color as default text and free labels become difficult to read.
Now go check out the Block Diagram section
I have an option to use Transparent free labels. Which, of course, I use even though it is NOT the default because I use wire labels and transparency is desired to avoid hiding wires!
Going one step further and thinking about it, why would transparent free labels be the default for FP but not BD? and why can I only change the behavior for the Block Diagram and not for the Front Panel?
Looking at the first picture again. Is the 1 pixel border really needed? a "Non transparent" free label does not need a border.
For the most part coersions can be broken down into two classes: lossy
(e.g. 64L to I8) and safe (e.g. U8 to U16). Why is there only one color
option for coersion dots? Could the vi analizer have seperate settings
for max allowable safe and unsafe coersions?
The loop stop function now accepts errors directly which is an improvement but there are many cases where loops must stop based on multiple sources.
If the stop function had several inputs (eg 4 - one one each side), this would allow multiple errors or stop commands all OR'd internally within the stop function to work without the clumsy OR function that is so commonly used.
There is no reason the OR couldn't be built into it and make everyone's live's easier. It would also simplify coding and increase speed of development.
Currently, when opening a command window with the System Exec function, the "wait until completion?" option performs two operations. It causes the VI to wait until the command is completed, and it suppresses the output in the command window. The output becomes available on the standard output terminal after the command has completed. This causes problems if you need to see what is happening in the command window, and you need the VI to wait until the command has completed.
It would add more functionality if these options were separate. One option, "suppress output?", would suppress the output in the command window and put the output on the standard output terminal. The second option, "wait until completion?", would make the VI wait until the command has completed.
I would like a better way to clear the list of recent files and recent projects in LabView. It is often disireable to clear the history when changing to a different project or a different user. Currently the user must close LV, edit the .ini file and restart LV. I would like to see menu selections added to allow the list of recent files and/or recent projects to be cleared.
I use a lot of clusters in some apps and using the in place element box can make the diagrams significantly larger and a bit unwieldy if you need to do some complex calculations. My idea is this:
right click on the increment icon:
Click on "Inline":
The box indicates that it is an inline operation so we also don't need to define the receiving cluster as labview knows that it is the same as the source cluster. The receiving cluster can now be placed where it is most convenient rather than being tied to the in place element box.
Right now, we can only edit a few select build specification properties, such as Icon, Name, and DisplayName. I think it would be very useful to be able to edit more of these properties programmatically.
Things I would like to be able to set/read via property nodes:
Build specification name
Build specification description
everything under "Version Information"
Other items would be useful as well, but those are the ones I care about the most.
It would be a very nice addition (especially when using XControls) to be able to actually programatically activate a right-click menu for a given control.
As it stands, one of the rather annoying disadvantages of an XControl is the inability to directly configure controls visible ont he Facade VI on a per-instance basis. The ability to programatically detect right-clicks and activate the appropriate right-click menu would be cool.
It would also allow for UI features like a google map delayed right-click menu appearance. If we double-click the right mouse button, zoom, otherwise (if a single click within a defined time period) open the right-click menu.
I've done this like a milion times! It's not very "pure", but how convenient would it be if the event structure itself kept looping until stopped?
This should be optional, like in the for loop ("Conditional Terminal"). For the event stucture, it wwhould be nice if wiring it is optional (unwired means keep looping), or that you can show\hide it on a per event basis.
Many people don't know, but there is a great VI in vi.lib called Open a Document on Disk.vi which does exactly as it explains. If you feed it the location of any document (Word, Excel, HTML, PDF, ANYTHING!) it will open it with its default program on the computer. Unfortunately this VI is hidden from the palette deep inside the vi.lib somewhere. I think this should be placed on the palette as it can be very helpful in application development.
The VI is located at C:\Program Files\National Instruments\LabVIEW 2009\vi.lib\Platform\browser.llb\Open a Document on Disk.vi (default LabVIEW installation directory may be different)
Ever right-click a VI, reference, property node etc and have the search window pop up showing it is in multiple places. Then you double-click one of them or press go to and the window closes, only for you to realize that you didn't click the instance you were looking for?! So, now you have to go through the whole process again. Not to mention you don't know which one you just clicked on so you don't know how to pick up where you left off. Disaster. Please, just have the window stay open and your recent selection stay highlighted after going to that instance!