Bob_Hansen wrote on Jun 18^th, 2006 at 2:20am:



There isn't a one-to-one correspondence. The internal version number refers to the application files format. Any version of Sesame can only read files that have the same internal version number. Ray may correct me, but I believe that all post beta 1.x.x version of Sesame have used the same internal version number and file format.

The version number always appears in the title bar.

The internal version is useful for support (and the supported user) - or at least it was during the beta testing. It may well become useful should we ever need to go through a translation layer to maintain backward compatibility. I hope that that will never be necessary.

Knowing the version in SBasic will only become useful if we implement conditional compilation - in which case it will need to be implemented as a pre-compilation constant, so it can be determined before the code is compiled to prevent compilation errors.

1.  When I set up a site, all versions are current and licensed on all workstations.
After I leave I have no control.  End user may modify, upgrade incorrectly, etc.

2.  When I inherit sites that were set up by someone else, I have no idea what I am running into. 

3.  By running a report that includes system information including Sesame versions, I can know immediately that I am going to have problems.

Although the version shows up in the Title Bar of the application, I was expecting to use the @Platform command to include the version in the report.  Actually, opening the program and looking at the Title Bar seems to be the only way to ID the version.  If I go to sesame.exe or sdesigner.ext and right click to look at properties and then at version, the Version information is not available as it is in most other executable files.