View Single Post
  #28   Spotlight this post!  
Unread 10-03-2015, 15:41
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 1,006
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Re: Driver Station Update fails to install

Quote:
Originally Posted by Crossle86 View Post
1) I caused the create date of the DS program to change by copying it, which I did while trying to figure out why I was not getting the updated program when I renamed driverstation.exe to driver station.exe. Still no explanation for that but I am willing to drop it since I seem to have the updated program in place now.
It makes sense that the creation date would change if you copied it.

I can't imagine what you were seeing either. Maybe a strange Windows installer thing? No idea.

Quote:
Originally Posted by Crossle86 View Post
2) Windows programs should always use a hard coded version or version based on the internal assignment of the 4 part windows version number, major.minor.build.fix or as I like to do major.minor.fix.build. If you use visual studio, all this can be managed automatically and your program can display the version embedded in the exe. If you are using LabView, then you have to manage the hard coded version yourself.
Sure. I agree. The versions we generate in our build system have the form major.minor.updatePHASEbuild. E.g. "15.0.0f7".

This is the form I intend to have used in all utilities, however the display in the title bar will be the abbreviated version. There is a set of rules for abbreviating that we use. You may notice that the DS title bar shows "15.0". That's what the above build version is abbreviated to.

Quote:
Originally Posted by Crossle86 View Post
3) This version should be displayed in the application title bar though many developers leave off the build in the title bar. The title bar version and the version displayed by the app should not be of different forms.
I agree that there should not be 2 different versions. The version generated by our build system is adapted to the Windows File Version that you were looking at in the properties. That 15.0.0.49159 is the same as 15.0.0f7. If you convert the 49159 to hex, you'll see it is 0xC007. The 2 most-significant bits indicate the phase. Options are d, a, b, f for development, alpha, beta, final respectively. The 14 least-significant bits are the build number.

Quote:
Originally Posted by Crossle86 View Post
4) Using file dates is not at all a good idea since the user can "change" the program version number.
As stated, I attempted to fix that, but didn't change it in both places. My bad.

Quote:
Originally Posted by Crossle86 View Post
5) Don't forget about the Driver user shell program not getting renamed. After a successful install of the update, the Driver user still runs the old program (hence the renaming I am doing). Note that I could have tweaked the registry to the correct program name, but I have our DS PCs set up to allow switching between the 2015 and 2014 DS programs as we still run last years robots quite a bit for demos and having the DS program name the same facilitates this switching. I know the 2015 is supposed to let you switch protocols, but this did seem to work when we first installed 2015 so we did it ourselves. And doing it ourselves allows us to switch out the custom display program we have for the upper part of the DS display.
I've reported this to our installer person.
Reply With Quote