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!
Currently the IMAQ (Vision) display windows maintain a separate event queue which can only be accessed by polling for new events. This should be integrated into the LabVIEW event handling so that all IMAQ events (e.g. Click Event, Draw Event, Move Event, etc) can be event sources for the Event Structure.
As of LV2010SP1, there is no good way to interact with the Right-Click menu of a control programmatically. You can create a custom right-click menu for a control at edit time, and as long as you save the menu with the control (saving it as a discrete *.rtm file doesn't work--see CAR #256160), you're in business.
But if you want to make sure multiple controls all have the same menu, you're pretty much out of luck. There is no way to programmatically load an *.rtm file for a control. The best you can do is build up the menu one item at a time using the menu primitive functions. And you have to do that on menu activation event, because you can't get at the control's menu reference any other way.
This is pretty kludgy.
The other solution is to make those controls strict type definitions, but that isn't ideal in a lot of cases. For instance, I want to make sure all the XY Graphs in my application have the same RTM API, so I could use a single strict typedef, but that sucks if I don't want them all the same size, etc....
So here's the idea: fix runtime menus for controls.
Add an "RTM Path" property for all LVControls to allow loading custom RTM files at runtime.
Add a "Runtime Menu" property to all LVControls to grab the menu reference at runtime.
Make sure that RTM files are loaded properly in EXEs (see CAR #256160)
There are occasions to interrupt a user generated Windows Shutdown, discard the event, and generate a Windows Shutdown event at a later point (e.g. to allow an acquisition to finish). This is not always possible within the Event case for Application Instance Close? (e.g. an acquisition is non-deterministic).
Why not add a Windows Shutdown event to the event structure and allow me to discard it? Can you also write a VI to generate a Windows Shutdown?
According to an NI applications engineer:
"The Application Instance Close? event triggers when LabVIEW application is closing. It does not tell you if Windows is shuting down. The only way to know when Windows is shuting down is to trap the WM_QUERYENDSESSION message that you were talking about yesteray. I have consulted with a R&D engineer to see if there's any way to do this in LabVIEW. The only possible solution we can think of is to write an .NET program that can trap the WM_QUERYENDSESSION message and trigger a event callback that you can register in LabVIEW using "Register Event Callback" VI . None of the engineers I've talked to have done this yet, so I cannot garantee if this will work."
Wouldn't it be more elegant to do this in LabVIEW?
Spurred by Darren's latest nugget, I think it would be an excellent addition to the feature to be able to retain wire values for all subVIs of a particular VI as well as the VI itself. Several times, I have found myself having to run a VI a couple times to get to the point where I can satisfactorily examine the data flow. There is a JKI RCF plugin by Vishal posted herewhich implemented this, but native functionality would be much preferred.
I'm not sure how best it could be implemented in UI so as not to disturb those who don't want this, and I can forsee a hairy situation arising if a particular subVI is called from a different hierachy later. Ideally, the subVI would retain values for the last execution in the retained hierachy, but obviously that's incorrect in the grand scheme of things. I'd love to hear other ideas on how to handle that scenario.
Too many times, a generic "Out of Memory" error pops up without explanation, source, or traceability. Sometimes it occurs intermittently when executing the exact same process. Tracking these mystery errors down takes more time than necessary and takes away from the efficiency and gains intended by the design of the automatic memory manager within LabVIEW. After some research and help from an application engineer, it is apparent that the memory manager is not well suited for modern PC's and OS's when needing to process larger amounts of data.
LabVIEW should be able to use all the application memory offered by the OS, not just the contiguous parcels it is lucky enough to find. Not only should it be able to use fragmented virtual memory but it should also be able to exploit more than just 75% of a 1GB application segment, particularly when 16 GB is installed on the motherboard.
For example, simple arrays of I16's are sometimes denied if they are only tens of MB in length and denied all the time if they are in the hundreds of MB. That doesn't even come close to the available memory capacity in the PC. Granted, those arrays are large compared to VI's written for simple GPIB devices twenty years ago but the need for larger arrays is now more prevalent with high-speed data acquisition and high-resolution imaging.
Why can't the memory manager grow with the latest PC memory capacities, motherboard architectures, modern OS's, and modern instruments that can acquire and transmit data with those array sizes? Isn't it time to challenge the need for contiguous memory? Can't more intelligence be added to the memory management strategy by not needing to copy large arrays redundantly that cause "out of memory" errors? Can't a memory manager be able to work within the fragmented virtual memory space of a Windows OS without having to reboot? Shouldn't it adapt to the OS environment instead of needing to prevent every other application from running in order to statistically gain more contiguous memory? Can't better automatic tracing and error messaging be delivered to the programmer prevent to much wasted time?
I have been impressed by the quality of service and detail of the online help to tiptoe around these limitations. However, it seems time to graduate from building contraptions to avoid the problem and instead apply that effort towards solving the problem. Are there plans to issue a new automatic memory manager to optimize the potential of modern PC's and OS's?
When I have large projects with lots of classes, Labview's edit time environment slows down to a painful crawl. Almost every meaningful action triggers a recompile that gives me a busy cursor for 3-10 seconds. My productivity falls off a cliff and I avoid making important changes in favor of the cheap hack. (The dev environment has high viscosity.)
I often wish there were a way to turn off the compiler while I make a set of changes. I'm not interested in the errors at every single intermediate state of the code while I'm making the changes. I *know* the code will be broken after I delete some nodes or wires. Let me turn the compiler off, make my changes, and then turn it back on for error checking.
I'm sure there are lots of different solutions to address this problem. My preference would be to make compiling faster so it is unnoticable. I doubt NI will ship me a new computer with the next release. My second choice would be to stop loading all of the class' member vis when any single vi is loaded. I vaguely remember a discussion about that some time ago and it wasn't practical to do that. That leaves me my third choice--more control over what automatically compiles when I make edits.
It could be something as simple as Ctrl-Shift clicking the run arrow to toggle auto-compiling at the vi level. Or it could be a right click option in the project window that controls auto-compiling for an entire library or virtual folder. Either would be okay; both would be nice.
(For that matter, it would probably be a lot cheaper if NI just shipped me a new computer...)
There needs to be a way of telling what cell in a table control was last selected and edited when the control loses key focus. As it is now the edit position property value becomes invalid (why?!?) and the selection start property isn't correct because it doesn't update as you tab between cells. So what you're left with is a control that is showing a cell still highlighted, but you can't get LV to tell you what the cell is.
Similar ideas have been posted before with even more options added to the String Probe. Maybe if we start with something simpler, we can expand from there.
I would like the String Probe indicator to resize, at least horizontally, to the full space provided in the Probe Display section of the Probe Watch Window. As the user resizes the Probe Display, the String Control would also resize.
It would be nice if this behaviour could also be extended to a String Array.
I would like to see an Option for Child Window. This option
will useful to keep open FP in Parent FP even when it is moved around,
I understand LabVIEW dose not support MDI, but simple Child
Window option will be helpful. Currently, I am using Windows API to do this,
but native supported function/ option can be big help (won’t have to use VI
server, Dynamic path builder to check application type vi, exe, llb, and others
useful things that needs be done..).
When developing a utility to traverse any control using VI Server and save its contents to a file (similar to the OpenG utility using Variant) it is quite challenging to find out the size of the array's data.
There are various workarounds, but all of these are relatively tedious and over-complicated.
Why don't we have a "array data size" read only value on the property node of an array?
I'm struggling with finding out the proper case in my case structure. It would be nice if the cases could be sorted automatically. Even better would be if we could change the sorting style (asc or desc).
Additional feature could be that the list of cases presented below should react for typing something like IntelliSense. For example, having the list of cases open as on the screen shoot below, if I type first few letters of the case name it should dynamically, (while I'm typing) go to the first case matched.
Current problem: unsorted long lists are difficult to search
As far as I can locate, this hasn't been posted on Idea Exchange yet.
What I'd like to be able to do is change the default colors and visibility of various components of block diagram items. For example, I might want to color the background and sub label of my timed looped structures so that they improve the appearance of my code, like NI has done in the Bioreactor example code with a free label and custom colors.
Rather than setting these colors/font sizes/label visibilities for each structure I place, I'd like to be able to set them only once. Currently, the sub labels' default visibility CAN be set in tools»options, but not the coloring.