LabVIEW Development Best Practices Documents

cancel
Showing results for 
Search instead for 
Did you mean: 

How do you code your 'About' dialog? Yes, this is a serious question...

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?

2014-06-20_08-34-20.png

Elijah Kerry
NI Director, Software Community
Comments
EricLM
Member
Member
on

Here is an example from the TSVN Toolkit.

TSVN Toolkit About.png

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.

Christian_L
Active Participant
Active Participant
on

Can we add a standard About Dialog template in the LV environment that provides the common requirements?

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
AristosQueue (NI)
NI Employee (retired)
on

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.

jlokanis
Active Participant Active Participant
Active Participant
on

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.

-John
------------------------
Certified LabVIEW Architect
Active Participant
Active Participant
on
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.

EricLM
Member
Member
on

All this discussion has made me rethink the TSVN Toolkit dialog. After some tinkering throughout the day, this is the current iteration.

New TSVN Toolkit About.png

vishots.com
Member
Member
on

This is much better Eric.

EricLM
Member
Member
on

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.

TroyK
Active Participant
Active Participant
on

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.


About_win.png

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
kegghead
Member
Member
on

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:

version.png

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.

FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

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:

version.png

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

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

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.

Get SVN version.png

Get Hg version.png

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
shew82
Member
Member
on

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):

TortoiseSVN WC Info.png

Contributors