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!
While debugging LabVIEW, we often have many VI windows open. It can sometimes be difficult to manage these windows, especially once the debugging session is over. I think we can improve this situation greatly with a minor change to the All Windows dialog. This dialog (launched from the 'Window' pull-down or by pressing Ctrl-Shift-W) currently shows a list of all LabVIEW windows that are currently open:
There are several columns of information describing all the open windows, and the list is sortable by clicking a column header. You can multi-select in the list and click 'Close Window(s)' to close multiple windows at once.
Idea: If we add a "Time Opened" column that lists time stamps of when the windows were first opened, it would be easy to sort by that column, then close all the windows that were opened during a span of time, i.e. while debugging.
While we're at it, there are several other usability enhancements that could be made to this dialog that seem to be low-hanging fruit:
Make the window a non-modal floater, with the list dynamically updating as windows open and close.
Add a 'Minimize Window(s)' button.
Give useful key navigation to the 'Close Window(s)' button (and any other buttons we may add).
I know there are other ideas about making debugging easier (don't show panels, etc.). I'm scoping this idea to improvements we can make specifically to the All Windows dialog to make debugging easier.
The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.
I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.
The enum has a built-in right-click menu to 'Select Item', but it's worthless... it does exactly the same thing as clicking on the enum directly:
I think we should replace the 'Select Item' right-click on enums and rings with a Quick Drop-like UI that lets you filter the enum/ring contents and select an item without having to scroll a giant list:
It's not a BUG it's a FEATURE.... that's why I have to present it here.
When the digital display is visible on a ring or enum, the option to display the radix should be present. I can't tell if a displayed value of "401" is hex or decimal without looking at the display representation...
(note: this idea is similar to this one, but different enough that I thought it warranted a new post)
LabVIEW 2019 will include a Clean Up Front Panel feature that repositions front panel objects to match their positions on the (already wired) connector pane. I think we should also consider implementing the opposite behavior, where you can arrange your front panel the way you want your connector pane, then assign that arrangement to the (currently empty) connector pane:
I envision the gesture used to employ this feature would be a Quick Drop Keyboard Shortcut, an entry in one of the drop-down menus, or a right-click on the Connector Pane.
I find it always a hassle to create an asynchronous call with the need of the "Open VI Reference" block. A strict static VI reference should be sufficient. Options should be either available in the properties via context menu, via property node or as input of the "Start Asynchronous Call Node".
I didn't go through the effort to create a property menu example, but here is an a graphic showing the help example and what I would wish for:
For about a decade and a half I have consistently changed the default block diagram grid spacing to 4. Why, to match the shift arrow moves. Hold it! Why not make the shift arrow moves equal the grid spacing?
CTRL+Click on an input is a great little tool to switch the input.
However, it only works when both inputs are wired. Often (, I or QD connected a wire wrong,) I feel like switching the input, before wire-ing the 2nd. Only to find it doesn't work...
Having to connect the 2nd wire just seems to disrupt the flow, being focused on the first input. Being forced to make things worse (connect two wrong wires) before being able to make it right just feels itchy to me.
It's a minor thing, but I never understood why it would be limited to 2 wires.
There are cases where a variant constant / control needs to have a data value. This can be done by right-clicking a control / constant, selecting Data Operations -> Copy Data, then right-clicking the variant and selecting Data Operations -> Paste Data. This can be time consuming for many variants.
The idea is to allow dragging and dropping of a control or constant onto a variant, and have the data copied to the variant:
OK, using Malleble VIs is cool. Imaging being able to not only wrap code around a variable datatype but wrapping an object around a variable datatype.
I personally have quite a few classes which do pretty much exactly the same thing but which only differ by the precide datatype contained within its private cluster. No changes in the number of elements, no changes in methods, only the datatype of the specific data.
Obviously, the datatype would have to be compatible with all methods and VIs of the class which use that data field or we would have broken code.
When I print a front panel containing a graph (who ever does that?) I get a stunningly beautiful publication-quality render of my data (overlooking the poorly done vertical y-axis label). However, all the many options of directly exporting a graph image (detailed here) ultimately provide only a screen-resolution image. See the contrast in image quality below:
Printed front panel vs exported graph image.
This idea has been discussed ad infinitum on the forum (see, for example, here, here, here, here, and here), but has never been adequately resolved. (Enlarging the graph for export does not work since graph elements do not scale, so lines, points and labels end up being far too small.) High time to implement a feature that has been in demand since (at least) 2002!
When you use Quick Drop to insert a division operation onto a wire: you almost always want the numerator to be automatically wired, and the divisor to be unwired. Yet, Quick Drop always wires up the denominator.
when using the shared variable multiple variable editor to bind shared variables between the PC and cRIO its an annoying UI experience when doing more than a couple of bindings.
While the dialog can be resized, the new size is not remembered when binding the next variable, and its current size / layout is not useful for showing trees.
Also it doesn't remember your last position in the tree - so every time you wish to bind a variable you have to click to expand cRIO, click Chassis, scroll and click Module then scroll and find the variable by luck as you can only see the first few characters then click again.
One of the most over-looked LabVIEW VI Properties, mentioned in all of the "Good LabVIEW Coding Practices", is the one called "Documentation", where you describe what the VI does, and its Inputs and Outputs (at a minimum). [NI Examples are certainly guilty of this].
I've been trying (and mostly succeeding) to ensure that every VI I write has such Documentation. Sometimes I make a mis-type, highlight "bad" parts, and hit the "Delete" (or backspace), then say "Oops, erased too much, let's undo that with ^Z". Except there is no Undo, or at least it isn't bound to ^Z here.
I can find no other place in LabVIEW that doesn't allow ^Z to replace deleted text. It works in String Constants, in Labels (whether Free Labels or names for Controls/Indicators), and other places.
To encourage LabVIEW Developers to use the Documentation property, can you please allow us to "undo a boo-boo" with ^Z?
Panel Actors provide a very extensible UI tool. There is simply nothing better than panel actors to build composite UIs, but we are still limited in that we can only insert UI elements into existing sub-panels or new windows. What if there was a simple function called Create SubPanel.vi with inputs of size and position, and an output of the reference to the created subpanel? What if closing the subpanel reference removed it from the front panel. Now we could create an infinitely complex UI at runtime. It should be a simple matter to build special support for this into the runtime environment. (I actually have no idea how hard it would be)
Use case: an acquisition UI with pre-defined display elements (graphs, gauges, numeric boxes, etc, etc), all created as individual panel actors. The user asks for a new graph element display during runtime. We programmatically drop a subpanel and then spawn the requested graph actor into it. User wants it moved, and we can do that with mouse events. Same for resize. User wants it gone and we can do that too. User wants 10 elements or 10,000. We can do that with no problem. Give us this and we can create literally any UI of any complexity, fully configurable by the user.