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!
If creating a reference to a .Net control you will observe that is reference type of ActiveXContainer is created which is sometimes confusing at a first sight.
Please introduce a .NetContainer (at least cosmetically at block diagram) for a better overview. If you are doing so, you could change as well the color of the ActiveX container with respect to the .Net container on the block diagram. If you have to change the programming interface, it would be much easier to spot where you have to do so.
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?
I search the idea forum and I see many Labview Upgrade suggestions as "DECLINED".
I know there are others out there like me, I HATE upgrading Labview. All the time required to update your custom configuration takes weeks. Heck, Labview upgrade isn't even smart enough to know all the software you're entitled to install...instead you have to force Labview to download and install your paid software individually.
Here's the deal, most of us don't have the time to upgrade because of all the maintenance we do to support our software. For instance, I have a paid Maintenance Agreement (as I do every year), I have been working in LV2015 and now it's time for me to upgrade my computer and I'm installing LV2018.
My wish, Have National instruments create a tool that would allow you to export all your custom settings, device drivers, and software requirements, etc..., so you could import these settings into a new version of LV. Making the upgrade process easier with a single tool.
Since it's so difficult to upgrade, I often wait 3 years or more before I try to upgrade. If it was more seamless to upgrade, I'd probably upgrade every release!
Anyway, we are all so busy we don't have the time to search these forums, so this request will be DECLINED too.
Perhaps NI should accumulate all of these requests to Upgrade and total them as one. Each individual request dies in a year because so many people are sticking with what works...often older versions of LV.
Sure, NI has a few upgrade tools, but, nothing that leaves you upgraded to the latest version of Labview without missing a step.
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.
Currently to AutoScale an axis once, you need to set the ScaleFitX/Y property to 1. However this is really just like calling a method since the value of the ScaleFit property remains whatever it was previously. As a result, I find this mechanism unintuitive and would prefer to use the invoke node to call a suitable method named ScaleFitX/Y since it is an operation that just happens at a moment in time rather than changing a property.
Current Method: Property NodeProposed Idea: Invoke Node
When you navigate through Labview code and go deeper in VIs hierarchy you end up with dozens windows open on your monitor. Lets create special action for opening subVI (like existent Ctrl+RightDoubleClick) which will close FronPanel BlockDiagram of VI from which you open new one ?
DVRs are references, and are automatically released when the VI hierarchy that created and "owns" it goes idle (stops executing). Commonly, the DVR just contains by-value objects, or LabVIEW references that are also automatically released, but an important use case of DVRs is wrapping a non-labview reference that must be properly cleaned-up. An example is an SQLite Connection pointer that must have a dll method called on it in order to release the database file it is holding open. Many dlls have similar pointers/handles that need to be properly closed. This is a headache for Programmers, who cannot rely on a stopped VI releasing its resources, often requiring restarts of LabVIEW to unload the dll.
A clean and easy solution to this problem would be to allow a "DVR Cleanup Callback VI" to be registered with the system when the DVR is created. That VI would be called if and only if the DVR is release because its calling VI hierarchy goes idle. This VI would contain the code to cleanup/close the contained non-LabVIEW references. Could have other uses, such as debugging.
I have developed multiple APIs that wrap non-LabVIEW dlls, and this feature would be a very significant help. Please consider it.
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".
Sometimes the order of the frames have to be changed in order for a VIM to work properly. It would be very useful if we could either rename the case itself or at least show the subdiagram label in the rearrange dialogue box.
Actually allow to add text in the frame case name would be much better and also help to navigate around when there is a lot of frames. All the frames are either ignored, declined and one accepted.
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):
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.
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.
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: