LabVIEW Idea Exchange

When a VI is deprecated in vi.lib or other LabView libraries, please include the word "Deprecated" or some similar, standard word, in the VIs description. When upgrading the LabView version, I can then easily search for any deprecated VIs in my application and can consider rewoking the code to use the replacement VI. 

Currently I use LabView through a Windows VirtualBox on a Linux Mint machine. I was told by a customer support employee that I should bring this idea to this forum. I chose this method because of the limited support for Linux even with the supported distro discs. I encourage NI to expand their Linux-compatible software to have the full capabilities that the Windows and Mac versions do for the distros that are currently out, and to expand the number of distros supported. Linux Mint is one of the most widely used flavors, and yet there is no support from NI.

Consider expanding programmatic modification of the Build Process.  There is already an Idea here to allow the Pre-Build Action to set the Version Specification before the Build Process (it happens during the Build process, after the before-the-change Version Specification has been cached and used in the Build).  However, other Specifications in the Build Spec would be very useful to be able to specify in a (true) Pre-Build Action.

• Target Filename (low priority)
• Destination Directory (I like to put Builds in Public Documents, but the Public Document folder can "move", though LabVIEW's Get System Directory can find it, so I could "pre-build" a path specific to the given PC)
• Build Specification Description (allows the user to include version-specific or Build-Time text)
• Version Information (in addition to Version Number, before being used, the other Fields might be useful).

I've noticed references on the Web to automated Builds, and know there are Build VIs that will do a Build.  I also know there are a set of "barely-documented" APIs that some have used for this purpose, but I don't know (other than the Set Version Specification, which doesn't work as I expected in a Pre-Build Action) of others.  I don't especially want to poke around inside the Project's XML file -- can we consider adding some other "Pre-Build" Set functions?  Could (for example) some of these "Build Properties" be set with a Property Node?  Maybe this functionality is already there and I've not found it ...

Bob Schor

Hi All,

I truly hope this hasn't already been inquired about in some manner, but if it has I'm not even sure what to search for.  Here it goes:

Up until now, I've kept a backup of labview.ini around so that if my computer dies or if I move to a new PC I don't have to spend time reconfiguring options.  It dawned on me tonight that there are a lot of other customizations that LabVIEW developers use.  If heavily relied upon, these customizations can be painful to lose.  For instance:

• Palette customizations (Including "Place VI Contents" or Merge VIs)
• user.lib
• custom icon templates

...you get the idea. (This is a pretty lame list, but it's all I could think of off of the top of my head)

There really ought to be a tool to consolidate all of these options down to the nitpicking details so that they can be exported in the form of a single file. (let's say a zip file, hypothetically)  The user could then access this tool under "Tools-Advanced->Import or Export user settings" or some similar option.

This way, if the user's PC becomes unusable or they are forced by IT department mandate to move to another PC, they could simply import their user setting file and the whole development environment would be configured to their liking, complete with customizations.

Did someone already think of this?

Thanks,

Jim