VI Reference Property Node inside sub-vi

[billings11]

Hey Folks,

I was always curious about why this is:

If I open a vi-reference in one vi, and pass the reference to a sub-vi, I can put a property node in the sub-vi and get all properties just fine - as long as I am in debug mode.  When I compile to an executable this problem has its own error message and everything.  So why does debug mode not throw an error too?  I'm just trying to deduce what the heck is the difference.

Check my painstakingly time-consuming example.

[billings11]

By the way, error 1043 "Feature not supported in this version."

Does that mean I can do this in 8?

[AESulzer]

The reason why an error was returned has nothing to do with the reference and everything to do with the "Revision Number" property. If you look at that property's write-up in the help, you will notice that this property is not available in the Run-Time Engine (i.e. not available to LabVIEW executables). The obvious reason for this is that executables are not editable, and thus do not have a revision number associated with them for this property to return. Hope this helps to clear things up!

Kind Regards,

[billings11]

Thanks for the answer.  However, let me say that they should change that.  Having a revision level in debug is helpful, but if you can't easily look at the internally tracked revision of the software in the executable it means you have to maintain your own entirely seperate revision control for distribution.  It sure would be nice to use the built in revision counters.  My application gets distributed to a couple hundred computers.  I have to support them, and I often release updates.  So what good is a built-in revision counter if I can't tell what revision it is in the distributed file?  So to get around that every time I change the software I have to manually update my own revsion tracking because the built in revsion counters don't help.  Not putting revision properties in the run-time engine basically limits their usefulness just to development.  It would have been useful in distribution as well.

[Dennis_Knutson]

Personally, I've never liked the built-in revision count for anything and especially not for revision control of executables. For one thing, I wouldn't like to make a lot of changes to the source code and have the release version of the executable jump from version 1 to 86 (as an example). You might want to look. I also prefer to indicate major and minor (x.x) releases and often x.x.x for things such as bug fixes. Using a source control system makes this easier as I can check out a project, make as many changes as I want to the source code, and then check everything back in at a specific version.

[billings11]

From the looks of it 8 may have an answer to this one as well.  I am looking forward to seeing what the project manager can do.

[AESulzer]

Just to throw my final two cents in on this discussion, if you are looking to keep track of versions between executable builds, LabVIEW allows you to do this if you create an installer for your executables. To do so, just select the Installer Settings tab from the Build Application window, and press the Properties button. This takes care of the problem that Dennis brought up in that the "version number" allows you to track only what is relevant to executables: number of builds rather than number of editing sessions. If you really want to keep track of the number of editing sessions, then you can always just use the revision number of your executable source as the version number of the executable.

I am also happy to announce that LabVIEW 8.0 allows you to assign version numbers directly to the executables themselves, so you do not even need to create an installer in order to incorporate version tracking! If you are an SSP subscriber, remember that your upgrade to LabVIEW 8.0 is included for free as part of your subscription, and you can actually download LabVIEW 8.0 now from this location before it ships to anyone.

Kind Regards,

[billings11]

When I discovered this issue I was coding an "About" modal screen that a user could select from a run-time menu.  This was supposed to work just like Labview's "Help->About Labview" screen, giving program description and version information.  So I tried to simply link in the revision from my vi's proerties because that would automatically keep a revision count and I didn't care what the format was as long as I could get a number.  I just wanted an easy way to check the revision, and its easy to give someone simple instructions to check the "about" screen.  Is there an easy way for a user to check the revision if all I do is put it in the application builder?  User-friendliness is key, because for me to support the application I will need to have them tell me the revision they are using over the phone or in an email.

Will it be possible to create this screen in 8?  If I just do it in the application builder, is there any way to link to it and build an "About" screen?  I don't really care what format.  It could be revision 728 as long as a user can get to it in a simple way.  Otherwise I will have to just build a screen with plain text on it and edit the text by hand every time I build an application.  Isn't there a more elegant way to do it?

Message Edited by billings11 on 10-20-2005 11:28 AM

[AESulzer]

With LabVIEW 7.1 (in which you assign a version number to your executable's installer), there isn't really an easy way check this version that I know of. However, in LabVIEW 8.0 (in which you assign a version number directly to the executable), this version number is stored in the Windows file properties. This means all you have to do is right-click the executable in Windows and select Properties, and there is a version tab that displays the version you assigned to it. In fact, in Windows XP, all you have to do is hold your mouse over the executable and the version number is displayed in the quick reference window that pops up.

As far as getting at this information programmatically in order to make an custom "About" window, I am not aware of any way to do this. It is theoretically possible, because all you need to do is tap into the Windows API and get at the Windows file properties for the executable, but there aren't any examples on doing this and it may be difficult -- probably more so than just updating a label on a front panel for each new version. Hopefully, though, the right-click method of getting the executable's version number will be user-friendly enough for you. If anyone has any success with programmatically getting the new exectuable version number added in LabVIEW 8.0, I invite you to post!

Kind Regards,

[billings11]

As soon as I receive 8 I'll definitely work on it for awhile and let you know!