Since there's still quite a lot of people out there using rather old versions of Lazarus and fpc I began to extend fpspreadsheet such that it can be used with versions down to Laz 1.0 / fpc 2.6.0. As I saw it's only a few procedures that are missing. I added a unit "fpsFixes" to the package into which I want to copy the missing code from newer versions. Of course, to avoid duplicate code, I want to check the currently used versions and want to make heavy use of "$IF"s. I know that the unit "LCLVersion" provides information on the LCL version (lcl_fullversion). My problem, however, is that LCLVersion introduces a dependence on LCLBase. The package laz_fpspreadsheet so far has been quite slim (dependence on FCL and LazUtils), I am not sure if it is a good idea to bloat the basic package.

Is there another way to tell that the package is currently compiled with an older Laz/fpc version?

I've got a couple of things that I try to keep compatible with as many versions of FPC and Lazarus as possible, in case I want to make them available to an "outsider" who will probably have minimal patience with problems relating to widget set and development tool version.

In practice, I make no attempt to go earlier than FPC 2.2.4 (there are reasons for avoiding earlier compilers that do not need discussion) together with Lazarus 0.9.24 (fixes_0_9_24 from svn), which is about the earliest that has LCLVersion. I'd suggest not trying anything earlier since by a happy coincidence that combination is one of the last that's compatible with gtk1 and also performs reasonably well with older Windows versions.

On unix, with a bit of work it's possible to get svn revision numbers from the compiler etc.

In practice, I make no attempt to go earlier than FPC 2.2.4 (there are reasons for avoiding earlier compilers that do not need discussion) together with Lazarus 0.9.24 (fixes_0_9_24 from svn), which is about the earliest that has LCLVersion.

This is much more than what I want, I think I'll stop with Laz1.0/FPC 2.4.0. I see now that I can get the basic spreadsheet functionality to work fine with these versions, but the visual controls and demos are rather fragile - this shows the enormous progress the LCL has made since summer 2012.

Currently, I avoid using LCLVersion by having some conditional defines which have to be activated in order to compile with old versions, and in the wiki page there is some documentation of these defines. It's not perfect, but provides at least a way to go.

2.4.0. I see now that I can get the basic spreadsheet functionality to work fine with these versions, but the visual controls and demos are rather fragile - this shows the enormous progress the LCL has made since summer 2012.

Currently, I avoid using LCLVersion by having some conditional defines

which have to be activated in order to compile with old versions, and in the wiki page there is some documentation of these defines. It's not perfect, but provides at least a way to go.

Maybe you can use two units for compatibility: one (e.g. FPCFixes) for the non visual parts that solely relies on FPC provided functionality. There you can use FPC_VERSION and friends to determine the compiler. The other unit (e.g. LazFixes) is only used for the visual components and thus can use LazVersion without problems.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150113/34f253a2/attachment.html>

Maybe you can use two units for compatibility: one (e.g. FPCFixes)

for the

non visual parts that solely relies on FPC provided functionality. There you can use FPC_VERSION and friends to determine the compiler. The other unit (e.g. LazFixes) is only used for the visual components and thus can use LazVersion without problems.

I am already using LCLVersion in the package with the visual components since it already depends on LCL anyway. The problem is the central spreadsheet package (spreadsheet data structure, file readers/writers, formula engine, etc) which I want to keep as slim as possible because there are certainly console applications which do not need the LCL. In particular, the spreadsheet formula implementation requires UTF8 functions (e.g. UTF8LeftStr() for the spreadsheet formula "=LEFT(...)") which are not yet contained in the LazUtf8 of older Lazarus versions (1.0). The package LazUtils which contains LazUtf8 does not depend on LCL, only on FCL. Therefore I thought that something like "LCL_fullversion" from LCLVersion would be a good indicator. Or is there something similar in the LazUtils package directly?