source compatibilty (*.pas & *.dfm) by Delphi versions

4
votes

Is there any information on the project file, source code and *.dfm file compatibility between the different DELPHI versions.

If I do not use the latest features of DELPHi XE3 can I still open the code base and compile using eg. DELPHI 2010 ? ( I Know Unicode Issues, or Component changes like INDY 9 to INDY 10 will block the down grading , but this an other topic for me)

The bad think e.g. not working : use your Delphi 7 project, open and compile using DELPHI 2010, you can not reopen the project with DELPHi 7 because some objects will have extened properties from opening the project with 2010. Manual rework back to DELPHi 7 style in that case is rather time consuming.

Can a developer team work together, were members are using different DELPHI XX versions?

1
delphidelphi-xe2delphi-7
Not easily (if at all). You can handle part of the issues by not sharing the project (.dproj) files, but there's not a lot you can do about what's stored in the .dfm due to properties being added and types being changed. There is absolutely no way to work in both D7 and D2010 using the same .dfms and .pas files at the same time - the differences are too many. You're in for tons of headaches if you try - I'd buy stock in a company like Wyeth-Ayerst (makers of Advil) if you plan on trying. :-) – Ken White
Teams must use the same Delphi version. Certainly I keep component libraries like jvcl portable and use dfm clean tools. But corporate apps are 1 version at a time – Warren P
is XE2 and X3 code compatible, except new features like FM2 vs FM ?Any link on information ? – user1769184
You can use Andy Hausladen's DFMCheck to help with conflicting properties inside DFMs. – Uli Gerhardt
DFMCheck only checks for components not their properties. – Andreas Hausladen

1 Answers

1
votes

It's possible to do what you want but I cannot imagine why you would want to. When we ported our app from D6 to D2010 we had shared source that would build in both versions.

This was purely a transitional arrangement. As soon as we were confident in the D2010 port, we severed the umbilical cord. And at this point we embraced the new features of D2010 with relish.

In order to make this work we used the following crutches:

  1. Helper functions to mitigate the ANSI/Unicode differences.
  2. Unit aliases to deal with unit renaming. For example the themes units changed names from D6 to D2010 and the unit alias feature hid that.
  3. Oodles of conditional code.

All this was needed because we had a porting task and so had to compile in both versions. The old version for our existing product maintenance, and the new version so that we could test and develop the port.

But I see no reason for you to do any of this., not least because it leads to very complex code. If you want your app to build in D7 then always build it in D7. Since you cannot use features of modern Delphi and retain compatibility with D7, why use anything other than D7? When you buy modern Delphi you also gain access to old Delphi versions.