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.
When creating a LabVIEW installer, in the Source File Settings dialog, I might change the attributes of several files in the same way. For example, I might make many files read-only and/or hidden. Currently, I have to click on each file and change its attributes. I would like to be able to choose multiple files (either by highlight, control-click, etc.) and change their attributes at the same time to the same setting.
I recommend the implementation of architectural warnings in the error log for detection of architectural mistakes. It would be nice if this could be toggled from the error log (like warnings) or had a viewer of some sort.
So far, I only have one architectural error that I’d like to catch, but I’m sure there are many others as well. Feel free to add suggestions for more architectural errors you'd like to catch.
Below I’m demonstrating the problems with bi-directional library dependence when using ppls. In this case the warning should state that: “Bi-directional dependence detected between Lib3 and Lib4”.
Initial state: Lib4 initial state and Lib3 initial state So we have bi-directional dependence which can only be seen through usage of multiple projects.
Lib3 built to Packed3 and replaces Lib3: Lib 3 replaced with Packed3 Everything seems fine and the replace operation worked.
Now look at the project used to build Packed3: Lib3 code locked Lib3 depends on Lib4 but Lib4 has had a replace operation so it depends on Packed3 --> Packed3 will always be in memory --> it is no longer possible to rebuild Packed3. Reverse replace not possible, so manual reverse is required to fix the code again.
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".
So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1. This means the function will wait forever until an event comes in. But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.
This idea is to have similar functionality when it comes to user events. I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it. If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running. In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.
What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.
But why not bookmark on front panel? I think at least free label with hashtag on front panel shall be listed in the bookmark manager as well. Bookmark on the front panel can be used as reminder for coming back in future.
(In LV2017) "Browse Relationshiips\Unopened SubVIs" shows a list of icons with truncated VI names - about 12 characters per VI. When looking through a list of similar icons, one has to hover over each icon to see the full VI name. This is impractical when hunting through tens or hundreds of SubVIs. If unopened SubVIs could appear as an alphabetically-sorted list of VI names, it would be very helpful.
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.
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 is something that started as a way to get data back from Actors in non-actor code (for example, web services). I've never cared for the blocking nature of Reply Msgs and the only other built-in option for getting back data is to make everything an Actor, which is not always an option. Promises solve both of those issues.
The basic idea is an enforced single-writer, many-reader cross thread datatype. In the current implementation, they are not much more than a locked-down, single element queue but you can actually do some pretty cool stuff with just that.
In the message sender, we create the promise and return it. The idea here is that the Actor owns the promise and will fulfill it. This gives us very low coupling for free.
Wait on Promise will wait for the Promise to be fulfilled. It is a malleable VI so that a Default Value (for timeout) and Type can be wired. Using the timeout lets us do other things while waiting for data.
Inside the Actor, we can set the value with Fulfill Promise. Remember, once the Promise is set, that's it, no changing it again. In fact, Fulfill Promise will error out if called twice on the same promise.
Something else really cool we can do is fulfill a promise with another promise. This may seem pedantic at first but it can help keep your code cohesive by passing the responsibility of fulfilling a Promise to another process. For example, if you have a message broker that just forwards a message, you can have the message broker fulfill it's promise to the caller with a promise from the callee.
We can also reject a promise with an error message that will be returned by any Wait on Promise that tries to read it. Rejecting a promise does fulfill the promise so you still cannot set the value later and you cannot reject a promise again.
Finally, we have Destroy Promise. It does exactly what it says on the tin.
I'd love to hit some more of the design points from https://promisesaplus.com/ (mainly adding Then callbacks) but I figure it's at a pretty good spot to share and get some feedback. I'd also like to try to figure out network communication at some point but that's probably a ways away (without some help anyway ).
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:
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.