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!
Title basically says it all but I'll elaborate. With increasing monitor resolution, a 16x16 glyph on a listbox doesn't work very well. On a 4K monitor this is awful tiny. This idea is to support larger glyphs in Listboxes, Multi-column Listboxes, and Trees. Glyphs are used in several places but on favorite of mine is to have item selection with checkboxes,example here. Allowing for these glyphs to grow with the row height would make them appear more cohesive. There is a threaddiscussing this topic, and a work around involving an array of picture rings that is placed over the listbox control. Here is a demo from that thread:
This work around is fine for simple things but doesn't scale well, and doesn't support trees easily. I for instance want to have two trees, where a user can drag and drop from one to the other with the larger glyphs coming along with the drop. Having to handle where the user dropped, and then dynamically building the glyphs to overlay on top of the tree, with indentation, and hiding when a tree's leaf is closedis a major pain. Please NI add a feature allowing for larger glyphs, and I would be so happy.
Error in terminals that are ignored/passed through by the VI without preventing normal execution should be marked differently in my opinion.
I've lost count of the times where I have to keep reading through the help files to check a function's error in behavior.
Examples: Release Semaphore, Close reference, Release Notifier
Then there're the functions that I have created that exhibit the same behaviour. People reading won't be able to tell at a glance if the error prevents execution when called from another function. As a quick fix I label the terminal 'error in (pass through)' or 'error in (ignored)', but it's not ideal.
Bonus points if this can be marked as such during development and the behaviour enforced/checked at compile time similar to the following (I know it will be difficult to reliably implement, so maybe warn instead):
I just ran into a situation today where I had a case structure with approximately 64 frames in it, 48 of which I wanted to remove.
The method of right-click the selector, select "Remove Case" (This step is right beside the "Insert Case" which is frustrating), repeat 48 times while the mouse is wandering all over the screen between the case selector and the menu selection..... cue carpal tunnel problems.
I really wished I could just either use the "delete" and "insert" buttons to mimic the appropriate menu selections
Be able to select multiple cases from the "Rearrange cases" window and select "Delete".
LabVIEW scripting makes it possible to automate repetitive tasks in LabVIEW, but it is often difficult to find the properties and invoke nodes to accomplish the task. It would be great to have a recording feature that watches what you do in LabVIEW, and then generates the corresponding code for it. I'm sure the engineers at NI could design it much better than any more specific ideas I could throw out, so I will leave the rest up to them.
When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.
I have VI's and projects saved in Chinese characters and they do not open in the English version of LabVIEW. LabVIEW is unable to read special character unless I change my system languages. I feel that LabVIEW should be able to read all different languages and not required to download different versions.
One of the fiddly things I seem to do more than I'd like is adjust the bottom of block diagram comments to the right height. At a minimum there, but also for similar text boxes on the front panel or subdiagram labels, etc. I'd like to have a snap feature that sizes to a multiple of the text height. Examples:
Currently (LV 2016) performing a "cut" on a file in the project explorer will warn the user that the file will be deleted from the project. Performing a "paste" can often result in an "unable to paste the contents..." message. This leaves drag and drop as the only method to reorganize code in the project explorer, but this is very cumbersome if there are a large amount of files and scrolling is necessary.
This idea is to propose windows-like cut + paste, where the "cut" item has ghosted text, but is not deleted. Once pasted, it is moved to the new location. This should have the same end effect as the current drag and drop feature.
This idea came to me from Darren's Nugget 2-23-2018 on Data Agnostic Probes I thought it might be useful to write a Probe.vim or specifically, a data type malleable probe to gain the ability to have some access to the data itself in a general smart probe and maintain the ability to display the data in a type specific manner.
One example would be a "Data History Probe" that displays the history values of any data type. I'm sure there are other good uses.