05-23-2018 01:29 PM
I had been building and sending out a vi to several of my internal customers, and they like it.
Over time it gets better. I do what they ask, and make 1-day turnarounds, and they like it.
Now we, and by "we" I mean they, are all getting overwhelmed with which version is which, or which copy.
I didn't tell them how to manage it; I only sent a installation that delivered a built application.
So now I want to say "use build 32 instead of build 12". Manually updating every time before build makes me "human glue" which is bad.
Yes all glue has human glue, and yes good glue needs human glue, but bad glue is 100% human glue, and this is a 100% human glue solution. There has to be an automated way to cause the build process to update the VI text.
So is there? (yes/no)
If so, what is it? Is it easy/simple?
05-23-2018 02:11 PM
I include a build version number in the "About" Window. See below:
The code is as follows:
The above works for the EXE version(run-time system), make a case structure when you are running in the IDE version to say something different like IDE Version.
mcduff
05-23-2018
07:47 PM
- last edited on
01-14-2025
03:26 PM
by
Content Cleaner
You can also include the version number in the exe/installer folder ([VersionNumber] or [ProductVersion]😞
05-23-2018 10:22 PM
There's a setting in the Executable Build Spec on the Version Number page to auto-increment the Build to ensure that each Build has a unique Version Number. You can use Get Build Specification Version (see McDuff's response) to get the Version Number from the Build Spec and display it in your Front Panel.
I use a slightly different scheme -- my LabVIEW code is managed by Subversion, and I've written a routine that takes the Revision Number of the current Working Version and uses that as the Build Number. I had originally incorporated doing all of this as part of a Pre-Build Action, only to find out that the Version Number is cached before the Pre-Build Action (i.e. "Pre-Build doesn't mean te hat it happens before the Build starts, but rather it happens sometime before thBuild ends, not very logical to me). One solution is to Build Twice ...
Bob Schor