LabVIEW Idea Exchange

Using the LabVIEW 2009 Build Spec (as an example) allows you to add a Destination to a Library which is very handy, as it means you can namespace VIs at build-time.

I would like to take this a step forward and then be able to set that new Library as a Sub-Library of another Library that already exists in the Project.

I would then want to be able to set the scope of this Sub-Library as well (relative to its now, Parent).

This combined with my Locking State Idea would allow be create a Distribution that would hide and protect a Support VI Library

As the Sub-Library would be Private Scoped (from above) and the Parent Library would be set Locked (does not show Private Members).

I currently can implement this using Scripting but it would be nice to have it native.

Cheers

-JG

I would like the option to edit the "Lock State" Properties of Project Items in the Build Spec of a Source Distribution. 

I would like this feature to work on a Virtual Folder and Library and be inherited by all children.

I am chasing the exact same functionality as the Password Protection option.

I currently have to implement this as a post-build process.

Cheers

-JG

Originally I thought this is what Daklu posted put that post got closed.

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...)

Make it to where you can make the user enter a activation code or serial number

A common need that comes up is the ability to randomize an array, yet there is no primitive that handles this. There are of course a few homebrew solutions, but it's tough to beat a primitive that accepts any dimension or datatype in terms of syntax and execution speed!

Note: This is not an Idea to create an array of random numbers, it only deals with taking an already initialized array and scrambling the locations of the elements.

I'd like a new property for an Indicator, which enables me to reduce its display-update rate to something less than the source-data update rate.

Reasoning:  When working with robotic systems, I often find myself adding large indicators to the Front Panel so I can get an easy to see indication of some new sensor's value (from across the room). 

This indicator is not necesarily needed on the final system so I don't want to spend a lot of time incorporating it into the BD.

The problem is that if a sensor is updating at 100Hz (like the ultrasonic sensor on the Robotic Starter Kit) you can burn a lot of CPU cycles trying to update a large bar graph with every data update.  In fact, on my system I just get a big flashing blob.  I invariably end up implementing some strategy to only display 1 in every 25 updates.  And in the process, I end up messing ip my neat BD layout.

It would be great if there was a built-in display property to take care of this for me.  See suggestion below:

The throttling property could be the minimum update interval, or the maximum update frequency, but the assumption would be that the GUI would just throw away any data updates that occured faster than the required display update rate.  In the example below I indicate that I only need 4 updates per second (ignoring the bulk of the 100Hz range updates)

I was considering submitting this in the Real-Time ideas forum, but it seemed applicable to any "fast" data acquisition system.

The LabVIEW compiler currently appears to use one core of a multi-core processor.  It would be nice if it fully utilized multiple cores to speed building of large projects.

Currently if you try deleting a registry key with sub-keys, LabVIEW will throw error -604 until all the sub-keys are deleted first.  There should be an option on this VI to automatically delete the sub-keys first.