Okay, this might seem silly at first, as the 'about' dialog (if you even have one) is easily the simplest and most trivial aspects of any software system you write. However, as a result, it's easily overlooked (at least for me). Case in point, I just realized that version 3.0.3.6 of my Measurement Utility has woefully outdated information in it (shown below).
I've been meaning to develop a way to auto-populate this dialog based on a build output so that the version number is always accurate, but I realize I'm not the first to have to figure this out.... so, any best practices out there? Anyone have some reusable code they feel like sharing for this purpose?
Here is an example from the TSVN Toolkit.
Everything on here is static, with the exception of the three version numbers. The TortoiseSVN and SVN version are pulled from the system (APIs for each component).
The toolkit version is set during VIPM build. There is a VI with a single string indicator with this value set as the default value. I have a pre-build script that gets the build version from VIPM and sets a new default value for the indicator and saves the VI. This is all done on an export of my source code, so the original VI is never touched during VIPM build.
For executable applications, I like to do something different. I will pull the application's exe version number using FileVersionInfo.vi. Once I have that, I can use it to populate the about dialog as well as append app window title bars with the version number (e.g. "My App - 1.2.3.4"). This makes it very easy for customers to quickly identify which version they are working with.
How would you know what version number to display? People encode the version number in all sorts of ways. And whatever way you pick, you still have the problem of remembering to bump it.
I also pull the exe version number when displaying the About and the Splash screens. In addition, I include a scrollable text control with a list of any plug-ins and their versions installed on the system (assuming your application uses a plug-in architecture. All my plug-ins include a method for getting their version and I use prebuild actions to bump this value when I build a plug-in.
People encode the version number in all sorts of ways. And whatever way you pick, you still have the problem of remembering to bump it.
This is because NI hasn't integrated the version number in all types of build specs into the environment. (Note that the situation of an RT app and system image really complicates this.) If we had access to that cluster, both read and write, from VI Server and the Build API, we could all easily manage it the same way.
Yes, you can use the Project Tag API in VI Server if you want to roll your own. But as you said, not everybody does this. And it still doesn't solve the problem of RT device images and target system configurations from MAX.
This is much better Eric.
Thanks Mike. I realized after posting it that it had not been updated since the first days of this toolkit, which has been overhauled quite a bit since then.
I use GetFileVersionInfo_DLL.llb to extract version information etc from the compiled exe.
As part of preparing the main VI for building, before I check it in to source control, I update the revision history then enable a case in a diagram disable structure that uses property nodes to copy the revision history to the VI description (as well as reset all controls etc) then disable it again before saving. Then at runtime the VI description from a property node is used as an input to the about window VI.
Most of the information in my About dialogs are static in my applications.
The version number however is determined at run-time so I don't have to worry about things falling out of sync. For years I've been using code like this:
Original source: lavag.org.
That code pre-dates some of the more useful path constants available nowadays but I still use it (if it ain't broke...). The work horse is FileVersionInfo.vi which is NI supplied but not found on the palette. Windows specific I suspect. I'll usually concatenate in some extra information such as platform architecture (32/64-bit) from a conditional disable structure since we compile some of our applications to both platforms.
kegghead wrote:
Most of the information in my About dialogs are static in my applications.
The version number however is determined at run-time so I don't have to worry about things falling out of sync. For years I've been using code like this:
Original source: lavag.org.
I added that piece of code from LAVA to my NI Week 2013 presentation and it has been working great for me.
kegghead wrote:
... The work horse is FileVersionInfo.vi which is NI supplied but not found on the palette. Windows specific I suspect.
It is Windows specific, but now you can have it in your pallete. Thanks to Darren Nattinger, you can go to VIPM and search for Hidden Gems and install a palette with some other goodies as well, you can find more information here:
https://decibel.ni.com/content/docs/DOC-35785
The function above only works in exes, if you want to have the version show when you are running on the development environment, you can use the Project API and grab the version from the build specification.
Other options include communicating with your SCC tool (SVN or Hg) via TortoiseSVN or via Hg, here are some VIs I have used in the past, you might need to play with them to make them work for your project. I haven't used them in a while.
If you're working with TortoiseSVN, another approach to getting file information is to use their COM Interface (http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev-com-interface.html):