The DoubleBuffered property added in dfm in Delphi 2009 does not exist in Delphi 2007

Question

Does this mean that I cannot split the form between delphi 2007 and 2009?

Answer 1

Yes. This is not possible if you do not remove properties that are not published in Delphi 2007 from DFM.

Answer 2

DoubleBuffered has been in TWinControl for some time now. The difference in Delphi 2009 is that it is published now. If you can only live by ignoring errors (and instead of using properties instead), this is a possible solution:

unit Delphi2009Form; interface uses Windows, Classes, SysUtils, Controls, Forms; type {$IFDEF VER200} TDelphi2009Form = class(TForm); {$ELSE} TDelphi2009Form = class(TForm) private procedure ReaderError(Reader: TReader; const Message: string; var Handled: Boolean); protected procedure ReadState(Reader: TReader); override; end; TReaderErrorProc = procedure(const Message: string); var ReaderErrorProc: TReaderErrorProc = nil; {$ENDIF} implementation {$IFNDEF VER200} type THackReader = class(TReader); procedure TDelphi2009Form.ReaderError(Reader: TReader; const Message: string; var Handled: Boolean); begin with THackReader(Reader) do Handled := AnsiSameText(PropName, 'DoubleBuffered') or AnsiSameText(PropName, 'ParentDoubleBuffered'); if Handled and Assigned(ReaderErrorProc) then ReaderErrorProc(Message); end; procedure TDelphi2009Form.ReadState(Reader: TReader); begin Reader.OnError := ReaderError; inherited ReadState(Reader); end; {$ENDIF} end. 

Then change the form declarations in your project to inherit from TDelphi2009Form, for example:

 type TFormMain = class(TDelphi2009Form) ... 

This will work at runtime - property errors will be ignored. To make it work during development, create only the design package, add designide.dcp to its require clause, and add the following block to it:

 unit Delphi2009FormReg; interface uses Delphi2009Form; procedure Register; implementation uses DesignIntf, DesignEditors, ToolsAPI; procedure ShowReaderError(const Message: string); begin with BorlandIDEServices as IOTAMessageServices do AddTitleMessage(Message); end; procedure Register; begin RegisterCustomModule(TDelphi2009Form, TCustomModule); ReaderErrorProc := ShowReaderError; end; initialization finalization ReaderErrorProc := nil; end. 

Install the package in the Delphi 2007 IDE and property errors for the DoubleBuffered and ParentDoubleBuffered properties will be automatically ignored when opening forms in the IDE. Property values ​​will be lost when you save the form in Delphi 2007, so you must initialize them instead of code.

EDIT : I added code to display reader error messages in the IDE message box:

Answer 3

Delphi projects have always been extremely convenient for porting to new versions. You should be more careful, but using the current code with older compilers is pretty straight forward. I supported code in Delphi 2005/2006/2007 that other people still needed to use in Delphi 6 and 7.

If you remove incompatible properties from DFM, they should work correctly in older versions without messing them up for Delphi 2009. The biggest example is the explicit * properties introduced in Delphi 2006. I have a home cooking "DFM scrubber" that removes them . Remember that these properties exist for some reason, so you should only clean those that you intend to have backward compatibility.

You may also consider investing in static code analysis tools such as CodeHealer or Pascal Analyzer. In addition to pointing out problems (especially CodeHealer) and helping clear your code, you can choose which version of Delphi to parse to make it easier to find incompatibilities except for DFM properties. And they can be automated as part of the assembly process.

Just notice. Share the source code, but keep separate projects for each version. This is especially important for Delphi 2007 and Delphi 2009. The later .dproj file uses the same extension, but it is not compatible with Delphi 2007. In addition, you may run some problems with incompatible resources.

Answer 4

Each form has a dfm file that contains settings for the properties of the form and its components. Some property values ​​have default values, so they are not saved if the default value is saved. Just did a little test:

• Create a form in 2009
• Add some standard controls
• Save
• Open it in 2006 (sorry no 2007 on this computer)

And he worked without messages. But maybe you are out of luck.

In Delphi, it is often difficult to exchange data between versions. Upgrading opportunities is great, but downgrading is difficult. Therefore, I do not recommend distributing form files between different versions.

As far as I know, it is not possible to add conditional definitions to the dfm file. But then again, do we really want this ... I would prefer a mechanism that ignores unknown properties.

Answer 5

You can safely add properties to the code in your OnCreate method for the form and wrap around them {$ IFDEF VER200} // NEW PROPERTIES {$ ENDIF}. You can leave DoubleBuffered out ifdefs, as it was in Delphi 2007, is simply inaccessible to the property inspector.

ONLY need to worry about the properties that you set other than the default values. For doublebuffered, you only need to worry about it if it is set to true.

When you upload a Delphi 2009 form to Delphi 2007, you will receive a warning that the property will be destroyed, just pay attention to these properties, since those you have to deal with.

I use just such a method to port my code to Delphi 2009 from Delphi 2006. Most of my projects contain several shared units and should compile in Delphi 2006 for the shipping version and Delphi 2009 for the “next” version. I also use a lot of the definition of {$ IFDEF UNICODE}, where I need to ensure that the string is the widest or runs depending on the subroutine.