From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Mads

Make App.Version return the application version, not the Run-Time version

Status: New

There is a logical glitch in the App.Version property; If you read App.Name you get the name of the built application...but if you read App.Version it's not the version of the application - it's the version of the RTE.

 

I use the application version in splash screens etc. - however today I have to manually write this multiple places because I cannot read the version number I used when building the application.

 

 

 

8 Comments
Jim_Kring
Trusted Enthusiast

It's probably too late in the game to change what App.Version means, at this point.

 

Now, you can can use"vi.lib\Platform\fileVersionInfo.llb\FileVersionInfo.vi" to do what you want 🙂

 

Get EXE Version Info.png

 

 

Mads
Active Participant

Hi Jim,

 

Thanks for the snippet. I was aware of the file info way of getting the info, but I still think they should correct the current behaviour.

 

You worry about the consequences if they do a change, but they already do this automatically for other incompatible upgrades when new versions of LabVIEW come out...I think they should add a property that returns the RTE version and do a replacement of the App.Version nodes if LV is asked to open a VI from an older version of LabVIEW. That way App.Version can be reserved for the version of the built app instead.

 

Generally - if there is one thing you (NI in thios case) should not start tolerating in an application it's small illogical operations. They do not have a big impact on their own, but make it a trend to accept such features... and soon they add up to less happy users....

Message Edited by Mads on 04-30-2010 02:25 AM
Mark_Ramsdale
Active Participant

Thanks, THis is just what the doctor ordered.

-------
Mark Ramsdale
-------
bwhite
Member

Unfortunately this work-around appears to only work on Windows executables and not on RT. Any update on resolving this so that the app.version reflects the correct information?

AristosQueue (NI)
NI Employee (retired)

We believe that the current behavior is the correct behavior. The existing App.Version property correctly returns the version of the application that is running. Your user code is hosted by the run time engine. We might change this except that knowing the version number of the runtime engine is important to many applications that are trying to talk to each other across various communications protocols, so this is not a property that we would want to lose.

bwhite
Member

In what way can I obtain the version information of the user code without having to reference the .cdf file which only updates this information if you deploy the startup application through the MAX software wizard?

AristosQueue (NI)
NI Employee (retired)

No idea. What I posted above was regarding the suggestion to change the existing property. Adding a new property to get some other piece of information is a different idea.

Mads
Active Participant

" The existing App.Version property correctly returns the version of the application that is running. Your user code is hosted by the run time engine."

 

This may be technically valid, but  I do not think it is valid/representative for people developing applications (!) in LabVIEW.

 

The Run-Time-Engine is just a necessary support package. As long as we have the application builder etc. (not the "user code builder"), people will view the resulting executable and their work as the main part of the app, the rest is just the RTE. (That's also why a print-out from the application should report itself as coming from the given application name, not LabVIEW(!)...so changing this in-house perception might fix other annoyances as well.)

 

 App.Version property should return the version number set by the application builder, and then there should be a separate property called the RunTime.Version. The fact that this was not chosen earlier does not make it any less correct, just much messier to fix in the most correct way.