LabVIEW Idea Exchange

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

At some point the LabVIEW installer stopped asking who I was and what company I work for during the installation process. Instead, the LabVIEW installer assumes that the "Registered Owner" and "Registered Company" of the Windows installation is what should be used.  I'd like it if,

1. The NI installer stops making this assumption and prompts me for this information.
2. It was a changeable option in LabVIEW (because changing every registry key doesn't seem to do anything)

When creating an installer for a Labview project it is possible to add Registry keys. But only with type REG_SZ and REG_DWORD.

Make it possible to add keys with other types. Often it is necessary to use the expandable String Type REG_EXPAND_SZ when adding path entries using for example %ProgramFiles% variable.

In newer LabVIEW versions, we can build executables that require SSE2 support an this option is even the default.

If we built an installer, we can select many other system requirements, such as the minimal OS version or the presence of the LabVIEW development system.  However, there is no option to prevent installation if the CPU does not support SSE2.

This means that an application that requires SSE2 support will install just fine on a non-SSE2 system and will fail only once we try to actually run.

I suggest to add a system requirement option to the installer builder so the application will not install if the hardware is not suitable. It should maybe even be enabled by default.

Here's how it could look like.

LabView uses the "primary" MAC address to identify a machine. If the MAC address changes, LabView assumes the software no longer has a valid activation and displays the following:

Like many developers, I have to use a VPN to connect to a corporate network. My VPN client creates a pseudo-interface with a (random?) MAC address each time I connect. LabView inspects this MAC address and decides I've installed LabView on a new machine, forcing me to go through the activation process again. I have to activate LabView about every 10 days. I have contacted support about this, and they have given me various work-arounds such as non-expiring activation codes (which required manually entering 10 activation codes, one per product, and only work until the next LabView service pack), or tying activation to the Disk Volume ID, which frankly I did not bother trying since the "eligibility on a case by case basis" did not mesh with the reality that every point release of LabView requires re-activation.

Now, I don't want to make too much of this. I've never had the activation fail, and it is pretty fast, so it's really not a big deal, but it is kind of silly to identify a machine based on a mutable property. Heck, on linux it's trivial to change the MAC address to anything you want! (I tried this with my VPN client, but it had none of it.)

I suggest the activation process something more stable, like the CPUID on Intel processors or, barring that, restricting the MAC address search to physical interfaces.

Thank you!

Rob Calhoun