Berocoder 16 Posted Friday at 11:38 AM Delphi have a good reputation of being compatible. You can take old source code and it often compile fine in latest Delphi. My team are in the process of upgrading from 11.3 to 12.2. I have been using 12.2 for a while. When I transfer a form, pas-file and dfm-file from 12.2 to 11.3 I got this error in 11.3 So 12.2 add a new property that is unknown in 11.3. It is a pity because now I have to be careful what to commit with 12.2 to not commit these attributes by mistake. Share this post Link to post
Angus Robertson 574 Posted Friday at 11:57 AM This error often happens with older versions, but usually just means the property is lost for the old version, which only matters if you have been already set it specifically for the newer version. I often open applications in both Delphi 11.3 and 2007, and ignoring properties never causes a problem. What is more annoying is the IDE inability to cope with a lot of similar errors, insisting on presenting dozens of modal dialogs if you open a large project group, you have to be so careful if what you click to avoid components not being removed from forms if they are not currently installed in the IDE. Angus Share this post Link to post
Berocoder 16 Posted Friday at 12:36 PM This error seems to be because of Developer Express upgrade. So should not blame Delphi IDE... 😁 Share this post Link to post
Anders Melander 1795 Posted Friday at 02:24 PM 2 hours ago, Berocoder said: When I transfer a form, pas-file and dfm-file from 12.2 to 11.3 I got this error in 11.3 It's been like that since Delphi 2. Why do you need to open a form in Delphi 11 that has been saved with Delphi 12? Regardless of this problem, you should always "be careful what you commit"; Review your changes and cherry pick the ones that are relevant so the important changes aren't drowned out by the noise. 1 Share this post Link to post
David Heffernan 2347 Posted Friday at 02:25 PM I don't think your expectations are reasonable. You can't expect to mix and match Delphi versions like this. When you are ready to upgrade, do it in a coordinated and unified manner. 2 Share this post Link to post
David Schwartz 427 Posted Friday at 09:33 PM (edited) The title of this thread is "Backward compability". That's referring to the ability to take OLDER versions of projects and build them in NEWER versions of Delphi, and it mainly applies to the language features and VCL. For example, you can still compile programs that declare 'object' types that existed briefly before the 'class' designation showed up. It has been deprecated for 25+ years, but it still works. You can even build old TurboPascal apps and there's a very good chance they'll compile and run without any issues. However, going from a NEWER version to an OLDER version has NEVER been supported. Needless to say, the error you're pointing to is not even in the language nor the VCL, so it's totally outside of Delphi's product domain. Meaning ... you're barking up the wrong tree. Third-party vendors frequently add updates to their libraries. Embt updates Delphi's language and the VCL very infrequently, mostly when a new major version is released. OTOH, companies like TMS Software (among others) frequently release updates based on bugs and requests submitted by their users. I don't know what library this is, but if it's DevEx, then I believe they update their subscribers quarterly. I've worked on projects where we used components from TMS, and in some cases, certain team members loved to complain about the frequency of updates, and they didn't bother doing them sometimes. I always update my libraries regularly, especially if there's something pushed out that fixes a bug or problem I encountered. If I do that and then commit an update, it's highly likely that someone who has not updated their TMS libs will encounter these same errors when attempting to build my code. That's not my fault! Nor does it have anything to do with either Delphi or "backward compatibility". (Frankly, it's a Project Management issue.) The moral of the story is, if you update a library and commit the code for it to your repo, then try opening that latest version on a machine that's got an older version of the library installed, then this is something that's VERY likely to happen. It doesn't matter what version of Delphi it is -- this is saying a property added to a class recently is missing from the version you've got installed on that machine, which is not terribly uncommon. You need to update the library, not Delphi. Edited Friday at 09:36 PM by David Schwartz Share this post Link to post
Berocoder 16 Posted Friday at 09:41 PM 3 minutes ago, David Schwartz said: The title of this thread is "Backward compability". That's referring to the ability to take OLDER versions of projects and build them in NEWER versions of Delphi, and it mainly applies to the language features and VCL. For example, you can still compile programs that declare 'object' types that existed briefly before the 'class' designation showed up. It has been deprecated for 25+ years, but it still works. You can even build old TurboPascal apps and there's a very good chance they'll compile and run without any issues. However, going from a NEWER version to an OLDER version has NEVER been supported. Needless to say, the error you're pointing to is not even in the language nor the VCL, so it's totally outside of Delphi's product domain. Meaning ... you're barking up the wrong tree. Third-party vendors frequently add updates to their libraries. Embt updates Delphi's language and the VCL very infrequently, mostly when a new major version is released. OTOH, companies like TMS Software (among others) frequently release updates based on bugs and requests submitted by their users. I don't know what library this is, but if it's DevEx, then I believe they update their subscribers quarterly. I've worked on projects where we used components from TMS, and in some cases, certain team members loved to complain about the frequency of updates, and they didn't bother doing them sometimes. I always update my libraries regularly, especially if there's something pushed out that fixes a bug or problem I encountered. If I do that and then commit an update, it's highly likely that someone who has not updated their TMS libs will encounter these same errors when attempting to build my code. That's not my fault! Nor does it have anything to do with either Delphi or "backward compatibility". (Frankly, it's a Project Management issue.) The moral of the story is, if you update a library and commit the code for it to your repo, then try opening that latest version on a machine that's got an older version of the library installed, then this is something that's VERY likely to happen. It doesn't matter what version of Delphi it is -- this is saying a property added to a class recently is missing from the version you've got installed on that machine, which is not terribly uncommon. You need to update the library, not Delphi. Yes I understand I was wrong. Btw it was a property in a new version of Devexpress that caused this problem. 1 Share this post Link to post