それは、デルフィ2007と2009の間でフォームを共有できないことを意味しますか?
5 に答える
DoubleBuffered は、しばらく前から TWinControl にありました。Delphi 2009 の違いは、現在公開されていることです。エラーを無視するだけで済む (代わりにプロパティを機能させない) ことができる場合は、次の解決策が考えられます。
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.
次に、プロジェクト内のフォームの宣言を TDelphi2009Form から継承するように変更します。例:
type
TFormMain = class(TDelphi2009Form)
...
これは実行時に機能します。プロパティ エラーは無視されます。設計時にも機能させるには、設計のみのパッケージを作成し、designide.dcp をその requires 句に追加し、次のユニットを追加します。
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.
パッケージを Delphi 2007 IDE にインストールすると、DoubleBuffered および ParentDoubleBuffered プロパティのプロパティ エラーは、IDE でフォームを開くときに自動的に無視されます。プロパティの値は、Delphi 2007 でフォームを保存すると失われるため、代わりにコードで初期化する必要があります。
編集: リーダーのエラー メッセージを IDE メッセージ ウィンドウに出力するコードを追加しました。
はい。Delphi 2007 で公開されていないプロパティを DFM から削除しない限り、これは不可能です。
Delphi プロジェクトは常に、新しいバージョンへの移植が非常に簡単でした。もっと注意する必要がありますが、古いコンパイラで現在のコードを使用することも非常に簡単です。Delphi 2005/2006/2007 で、他の人が Delphi 6 および 7 で使用する必要のあるコードを保守しました。
DFM から互換性のないプロパティを削除すると、Delphi 2009 でそれらを台無しにすることなく、古いバージョンで適切に機能するはずです。最大の例は、Delphi 2006 で導入された明示的な* プロパティです。これらを取り除く自家製の「DFM スクラバー」があります。アウト。これらのプロパティは何らかの理由で存在するため、下位互換性を維持したいプロパティのみをスクラブする必要があることに注意してください。
CodeHealer や Pascal Analyzer などの静的コード分析ツールへの投資を検討することもできます。問題(特に CodeHealer)を指摘し、コードのクリーンアップを支援することに加えて、分析対象の Delphi のバージョンを選択できるため、DFM プロパティ以外の非互換性を簡単に見つけることができます。また、ビルド プロセスの一部として自動化することもできます。
ただのメモ。ソース コードを共有しますが、バージョンごとに個別のプロジェクトを保持します。これは、Delphi 2007 と Delphi 2009 の間で特に重要です。最近の .dproj ファイルは同じ拡張子を使用していますが、Delphi 2007 と互換性がありません。互換性のないリソースで問題が発生する可能性もあります。
フォームの OnCreate メソッドのコードにプロパティを安全に追加し、それらを {$IFDEF VER200} // NEW PROPERTIES {$ENDIF} で囲むことができます。DoubleBuffered は、Delphi 2007 に存在していたため、ifdef の外に置いておくことができますが、プロパティ インスペクタでは使用できません。
デフォルトとは異なるプロパティを設定することだけを心配する必要があります。doublebuffered の場合、true に設定されている場合にのみ、これについて心配する必要があります。
Delphi 2007 で Delphi 2009 フォームをロードすると、プロパティが破棄されるという警告が表示されます。これらのプロパティは対処する必要があるため、それらのプロパティを書き留めておいてください。
私のプロジェクトのほとんどには、いくつかの共有ユニットが含まれており、出荷バージョンでは Delphi 2006 でコンパイルし、「次の」リリースでは Delphi 2009 でコンパイルする必要があります。また、ルーチンに応じて、文字列がワイド文字列またはアンチ文字列であることを保証する必要がある場合、{$IFDEF UNICODE} 定義を多用します。
各フォームには、フォームとそのコンポーネントのプロパティ設定を含む dfm ファイルがあります。一部のプロパティ値にはデフォルトがあるため、デフォルト値が保持されている場合は保存されません。ちょっとしたテストをしただけです:
- 2009 年にフォームを作成する
- いくつかの標準コントロールを追加します
- それを保存
- 2006年に開いてください(申し訳ありませんが、このPCでは2007年ではありません)
そして、それはメッセージなしで機能しました。しかし、あなたはそれほど幸運ではないかもしれません。
Delphi では、バージョン間でデータを共有するのが面倒なことがよくあります。アップグレードの可能性は素晴らしいですが、ダウングレードは面倒です。したがって、異なるバージョン間でフォーム ファイルを共有しないことをお勧めします。
私の知る限り、dfm ファイルに条件定義を追加することはできません。しかし、繰り返しますが、私たちは本当にそれを望んでいるのでしょうか... 私は、未知のプロパティを無視するメカニズムを好みます。