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 find it a real pain to add simple formatting to text in labels and decorations (free labels / floating text). I really wish that Ctrl+B (Bold), Ctrl+U (Underline), and Ctrl+I (Italics) would do thier expected magic.
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.
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.
Currently, if you want to enter in multiple elements in an array, you have to click on the empty element before typing. It would be more effecient to be able to press tab to enter another element in that array.
I suggest having a feature that would allow us to add "virtual" error terminals to any VI by right-clicking any VI and selecting "Add Virtual Error Terminals...". These virtual terminals would do nothing more than act as pass-through tunnels to facilitate data flow. This would allow us to minimize the use of sequence structures:
In LabVIEW if I want to use a property/method of a control I have to right click and select property. Same for second control I want to use same property I have to do same operation again. My idea is if we select all the controls and right click, some common property like value, visible and etc..... Should display and by selection it generate automatically. This can reduce my application development time.
So if this key feature is there in LabVIEW we can select multiple controls or properties and perform some basic operations to reduce our application development timing.
Thanks and Regards Himanshu Goyal | LabVIEW Engineer- Power System Automation Values that steer us ahead: Passion | Innovation | Ambition | Diligence | Teamwork It Only gets BETTER!!!
The useful feature of having an arrow connect a free label to the part of the code it refers to was added in LV 2013. However, there are cases where a label refers to multiple objects, so you would want to point an arrow to each of those objects. Currently this is unavailable. I suggest that this feature gets implemented in following LV releases. It makes block diagram documentation just that bit better.
It would be nice if under options that highlight execution speed for debugging was configurable. It could also be not an option but placed just next to the light bulb icon. With experience we become able to folloe the code much faster and having 2 or 3 speeds of highlight execution could save some waiting time. I know that there are many debugging options already but sometines the old light bulb is easiest.
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?
If you wanted to use a lot of functions from the same palette, you have to either keep going back through the context sensitive Replace/Create menu or manually search back over to the palette through the Functions palette to get to the functions you need.
Wouldn't it be nicer if we could pin that palette down directly from the context menu?
If this has already been implemented in LabVIEW 2012, give this idea a miss!
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.
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.