Is there a way to retrieve the version info that is stored in the project file at runtime?

Luiz

Luiz Americo Pereira Camara wrote

Is there a way to retrieve the version info that is stored in the project file at runtime?

If possible i also would like to get the compilation date

Luiz

Luiz Americo Pereira Camara wrote

Is there a way to retrieve the version info that is stored in the project file at runtime?

A way - yes, but it is not easy. I thought to create some simple access methods but no time for this currently.

Best regards,
Paul Ishenin.

Luiz Americo Pereira Camara wrote

Is there a way to retrieve the version info that is stored in the project file at runtime?

Instantiate a TProcess class and execute '<app> -v' (obviously your app needs that command line param support) and read the output. This is the safest way and most cross-platform way I could find.

I simply ignore the "version information" tab in the Project Settings dialog, because it only works for one out of all the supported platforms (windows).

You can even have a command line parameter that outputs similar "version information" as that tab, but in the format key=value, so when you read that output directly into a TStringList, it is even easier to parse and use.

Regards,
- Graeme -

Luiz Americo Pereira Camara wrote

If possible i also would like to get the compilation date

const
  cCompileDate = {$I %date%};
  cCompileTime = {$I %time%};

I couldn't find a way of formatting the date and time to my locale (under Linux, not sure for other platforms). It seems to be hard-coded, so you will have to parse and format it manually.

Regards,
- Graeme -

Graeme Geldenhuys wrote

I simply ignore the "version information" tab in the Project Settings dialog, because it only works for one out of all the supported platforms (windows).

I've been thinking about looking at integrating it in somewhere as a resource. I currently integrate my Changelog and Release notes into the binary as compressed resources using lazres. I just decompress them into streams as required and use loadfromstream() in memo components to display them.

If I can figure out how to integrate simple resources using the new fpc resource stuff, I'll do it that way.

Regards,
Brad

Version info from the project version info tab is usable on all platform and there is a cross-platform way to retrieve it but it requires deep knowledge of windows resources. I can create a class which will retrieve all the written info from the version resources. There are no big problems here. The only question I have whether it is a part of LCL or more belongs to RTL/FCL? I think that the proper place for such a class is somewhere inside fcl-res package but the goal of that package differ a bit.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

Version info from the project version info tab is usable on all platform and there is a cross-platform way to retrieve it but it requires deep knowledge of windows resources.

This makes no sense. :-) It's cross-platform, but requires deep knowledge of MS Windows? How is MS Windows knowledge cross-platform?

more belongs to RTL/FCL? I think that the proper place for such a class is somewhere inside fcl-res package but the goal of that package differ

I've seen comments here and there about FCL-res package, but haven't looked at it in detail. But my first thought would also be that such version info retrieval class be in FCL and not LCL.

Regards,
- Graeme -

22.01.2010 14:38, Graeme Geldenhuys ?????:

Yes, because resource support in fpc made in a
'windows-like'/'delphi-like'. Nothing bad in this but work with resources requires knowledge of windows structures which are used to store different resource info into executable. And version info resource is not the easiest structure.

Best regards,
Paul Ishenin.

2010/1/22 Paul Ishenin :

Yes, because resource support in fpc made in a 'windows-like'/'delphi-like'. Nothing bad in this but...

Ah, now I get it. Piggyback on existing designs.

And version info resource is not the easiest structure.

I don't think Microsoft has ever defined a easy to use structure. They are the best example of a vendor that always does over engineering. ;-)
Marco and I had a similar debate about the CHM file structure compared to IBM's INF file structure.

Thanks.

The returned value is also hardcoded under windows. I need to parse using ScanDateTime from DateUtils

Luiz

2010/1/22 Luiz Americo Pereira Camara :

...

The returned value is also hardcoded under windows. I ?need to parse using ScanDateTime from DateUtils

I wonder if we should file that as a bug for FPC?

I think of that (in fact i started writing the bug report) but since is defined at compiler time it will not be possible AFAIK to use the ShortDateFormat at runtime (say you compile in a yyyy/mm/dd system and run in a dd/mm/yyyy you will still get yyyy/mm/dd)

Luiz

A better solution would be to implement a macro that returns a TDateTime value instead of a string

Luiz

Have al look at fpc_src\packages\fcl-base\src\win\fileinfo.pp.

Ingo