How do I display the VI Version number on the front panel?

[waldemar.hersacher]

I have the same situation because all of my customers get the application along with the sources.

This delivery is on a CD where the CD and not only the session is closed. This way my customer nerver has a chance to change the original delivery without destroying it.

Next my customer has to prove that he is using my delivery. The information in the about box is enough to determine the version if he has several of them.

Most of my customers want a long term relationship so if he is making any changes he will say it to me. This will allow us to talk about the facts: His change caused the bug, the bug was in but the program was never used this way before, the change has a side effect causing a bug
elsewhere.

Customers who want you to remove their bugs will have an easy chance to set the revision number to the value the VI had in your delivery.
That's the way it goes:
(LV6.x)Make changes to your VI. Then delete the history. Save the VI. With VI server open the VI, save the VI so often as the revision number was before.
(LV7)Make changes to your VI. Set the revision number using VI server to the value you want.
You can't rely on the revision number to reflect the information you need.

The only reliable mechanism is to make any sort of checksum or hashing for each of your files. You can use a CRC32 or MDA5 code. Make a human readable document which contains all the filenames, size, date and time stamp and the calculated code. Put this on the CD. Calculate this number for the document and put the information on the label of the CD. Do not forget to put he tool also on the CD so your customer can verify the numbers of his own.

Waldemar

[Eriquito]

Another option that might be useful is calling into the Windows .NET API to reveal the version number of the EXE itself:

Determining the Version Number of LabVIEW Executables

[dmafackler]

I have encountered the same concern: VI history:revision is available only in the development environment.

Use-case: decorate a UI with a unique version number. An integer value that increases with VI change suffices. I see the value for complex multi-tabbed interfaces too. Starting simple for a suite of apps in development that are regularly deployed for end-user test/review/feedback.

Propose to decorate the application INI file at build time. Example: given an application named Collector.exe, Collector.ini will be modified to include a property "history.revision.ui.collector=777", the source VI will be modified to read the run-time property specific to it.

One colleague proposes taking all the vi paths and revisions and stuffing them in a JSON blob well-known to, and searchable by to the run-time system and distributed components.

Looking for pointers, examples along the lines of decorating / modifying the INI file at build time. E.g. when does the default build process create the application INI? Where does it get staged while an EXE build is created?  Is it better to decorate before the default process (pre) or after (post)?

Not presently familiar with that infrastructure other than that it exists.

[wiebe@CARYA]

1) Keep your code in source code control.

2) Keep release nodes in a txt file (in SCC), in version sections. (Optionally) use issue numbers from an issue tracker.

3) When you build, increase the version manually.

4) When you build, commit and tag the source code

5) Get the version from the exe.

Now you have full traceability between code, features and versions...

Of course you could replace 5) with "read from the release nodes file"... I'd go to the source: the exe (PI 😋). The release nodes are editable, even accidentally the exe isn't (easily). Also, during testing you might want to replace the exe with older or newer versions. You'd get proper versioning even if you forget to copy the release notes.

[jcarmody]

We do this:

Do whatever you want with it once you get it.  We put it in the title bar:

[crossrulz]

Here is what I started doing with my last project.  I use the Conditional Diagram Disable Structure so I can get the build specification version build number in the IDE or the executable's version when in an executable.

[MartinP]

This one does the trick for me.

Martin

[wiebe@CARYA]

---

@MartinP wrote:

This one does the trick for me.

Martin

---

Close that reference though...