特集 .NET完全対応で生まれ変わったDelphi 8 泉 祐介 2004/06/26
Page1 Page2 Page3 Page4

Windowsフォーム・アプリケーションの開発

　Windowsフォーム・アプリケーションは、VCLを利用せずに、.NET Frameworkクラス・ライブラリに含まれるWindowsフォーム（具体的にはSystem.Windows.Forms名前空間に含まれるクラス群）を利用して作成したアプリケーションである。

　Windowsフォーム・アプリケーションを開発するには、メニューから［ファイル］−［新規作成］−［Windowsフォームアプリケーション］を選択する。すると、VCLのときと同じように新しいフォームが画面中央のウィンドウに表示される。

Windowsフォーム・デザイナ

メニューから［ファイル］−［新規作成］−［Windowsフォームアプリケーション］を選択する、VCLのときと同じように、新しいフォームが画面中央のウィンドウに表示される。

　画面右下のツール・パレットを見ると、そこに含まれるコンポーネントが変化していることに気付く。だが、VCLとWindowsフォームとで異なるのはそれだけではない。下の画面を見てほしい。

画像表示プログラム（Windowsフォーム版）のフォーム・デザイン

VCLで作成した画像表示プログラムと同等なものをWindowsフォームで作成しているところ。Windowsフォームのデザイン画面は、その表示や操作性がVS.NETに近い。

　この画面は、先ほどVCLで作成した画像表示プログラムと同等なものをWindowsフォームで作成している様子である。画面からも分かると思うが、Windowsフォームのデザイン画面はその表示や操作性がVCLのものとはかなり異なり、むしろVS.NETのフォーム・デザイナに近い。

　Windowsフォームのデザイン画面では、ユーザー・インターフェイスのないコンポーネント（非ビジュアル・コンポーネント）をフォームに追加すると、そのコンポーネントがフォームの下にあるトレイに表示される。また、メニュー項目は、メニュー・デザイナのような専用のウィンドウではなく、フォームに表示されたメニュー・バーの上で編集する。

　ユニット・ファイルの内容は次のとおりである。筆者が記述したコードはVCLのときと同じように番号を付けた個所だけだ。「Windowsフォーム デザイナによって生成されたコード」といい、その中身といい、自動生成されるコードはC#やVB.NETを使用した場合とそっくりである。

　なお、コンポーネントを初期化するコード（コンストラクタの呼び出し、プロパティの設定など）がユニット・ファイルに直接記述されることから、Windowsフォームの場合はDelphiフォーム・ファイルのようなファイルは存在しない。

unit ImageWFM; interface uses   System.Drawing, System.Collections, System.ComponentModel,   System.Windows.Forms, System.Data; type   frmMain = class(System.Windows.Forms.Form)   デザイナ管理コード   strict protected     /// <summary>     /// 使用されているリソースの後処理を実行します。     /// </summary>     procedure Dispose(Disposing: Boolean); override;   private     { Private 宣言 }   public     constructor Create;   end;   [assembly: RuntimeRequiredAttribute(TypeOf(frmMain))] implementation Windows フォームデザイナが生成したコード procedure frmMain.Dispose(Disposing: Boolean); begin   if Disposing then   begin     if Components <> nil then       Components.Dispose();   end;   inherited Dispose(Disposing); end; constructor frmMain.Create; begin   inherited Create;   //   // Windows Form デザイナのサポートに必要です。   //   InitializeComponent;   //   // TODO: InitializeComponent 呼び出しの後のコンストラクタコードを追加   // end; procedure frmMain.mnuOpen_Click(sender: System.Object; e: System.EventArgs); var   bmp: Bitmap; begin     if dlgOpen.ShowDialog(self) = System.Windows.Forms.DialogResult.OK then   begin     bmp := Bitmap.Create(dlgOpen.Filename);     imgView.Image := bmp;     imgView.Size := bmp.Size;   end end; procedure frmMain.mnuExit_Click(sender: System.Object; e: System.EventArgs); begin     Close; end; end.

画像表示プログラム（Windowsフォーム版）のユニット・ファイルの内容

Windowsフォームに対応するユニット・ファイルの内容。実際に筆者が記述したコードは番号の付いている個所だけで、あとはDelphiによって自動生成されたコード。

ユニット・ファイル（imagewfm.pas）のダウンロード

［ファイルを開く］ダイアログを表示し、指定されたファイルから画像を読み込んで表示するコード。 　 メイン・フォームである自分自身を閉じ、アプリケーションを終了させるコード。

　アプリケーションをビルドして実行すればVCLフォーム・アプリケーションのときと同じように動作するはずだ。

　ところで、「過去のバージョンとの互換性」の項ではDelphi言語仕様の変更点については解説しなかった。最後に、この「Delphi言語仕様の変更点」を解説し、本稿を締めくくるとしよう。

Delphi言語仕様の変更点

　ポインタなど一部の変更点についてはすでに触れたが、Delphi 8の言語仕様の変更点はほかにもいくつかある。まずDelphi 8では次のような言語概念が追加されている。

• 名前空間
• スコープの追加（strict privateとstrict protected）
• 静的メソッド、プロパティ、フィールド
• 静的コンストラクタ
• ネスト型
• シール・クラス
• Final仮想メソッド（シール・メソッド）
• 演算子のオーバーロード
• カスタム属性
• クラス・ヘルパー構文

　これらの多くは、.NET言語の仕様であるCLS（Common Language Specification）に準拠するために追加された概念だ。

　名前空間についてはここで触れておこう。

　Delphi 8では、unit節で宣言するユニット名がそのユニットの名前空間になる（正確には、ドットがある場合とない場合で実際の名前空間が変わってくるが、その詳細については割愛する）。これに伴い、uses節は使用する名前空間を指定する文となった。ただし実際には、ユニット名がそのまま名前空間になっていることから、uses節に指定する文字列はさほど変わらない。単純に.NET Frameworkの名前空間を指定できるようになった程度である。

　なお、前述したようにVCL for .NETの各クラスはBorland.VclあるいはBorland.Delphiで始まる名前空間に含まれるが、これらの名前空間を指定する場合はBorland.VclあるいはBorland.Delphiの部分を省略できることになっている。従って、例えばBorland.Vcl.Formsは単にFormsと指定すればよい。

　このほか、.NET環境に適応するために変更された仕様も存在する。例えば、前述したVCL for .NETにおけるポインタの排除もその1つだが、それ以外にも（詳しくは触れないでおくが）ガベージ・コレクションの存在、Win32 API呼び出しにおけるマーシャリング（マネージ・コードとアンマネージ・コードの間での型変換）の存在などといった事項に対応するための変更点がいくつか存在する。

総評

　本稿では、.NET Framework対応の開発環境として生まれ変わったDelphi 8の機能を、Windowsアプリケーションの開発を中心に検証した。

　筆者の感覚では、VCL for Win32とVCL for .NETとの互換性はかなり高く、「過去のバージョンとの互換性」のところでも述べたが、多くのコードはほとんど変更することなく.NET Frameworkに移植できるのではないかと思われる。「過去の資産」を大切にするボーランドの姿勢が、このVCL for .NETにも表れたといってよいだろう。

　気になる点としては、VCLフォームのコンポーネントとWindowsフォームのコンポーネントを同時に使用できない点がある。もちろん、VCLフォームとWindowsフォームではコンポーネントの設計はかなり異なるし、VCL for .NETの多くの部分はWindowsフォームに依存せずに設計されているので、両者のコンポーネントを1つのフォーム上で使用するのは技術的に相当な無理がある。それを考えれば、このような制限が生じるのはやむを得ないのだが、結果としてVCLフォームからWindowsフォームへの移行をより困難にしている点には注意しなければならない。もっともVCLが今後なくなっていくというわけではないので、無理にWindowsフォームに移行する必要はないのだが。

　それから、これは筆者個人の意見になるが、製品のラインアップからPersonal版のような廉価版が消滅したのは、個人ユーザーとして少々残念である。新しいDelphiを気軽に試してみよう、というわけにはいかなくなってしまったためだ。

　いろいろと書いてきたが、何はともあれ、本製品によってDelphiユーザーは新しい言語を覚えることなく.NET Frameworkを対象とした開発が可能になった。次世代のWindowsのLonghorn（開発コード名）では、.NET FrameworkをベースとしたWinFXがAPIとして採用されることが発表されている。それを考えると、これを機会にいまのうちから.NETの世界に慣れておくのも悪くはないだろう。

INDEX
	［特集］.NET完全対応で生まれ変わったDelphi 8
	1．.NET完全対応のDelphi 8
	2．VCLフォーム・アプリケーションの開発
	3．VCLを.NET環境に移植した「VCL for .NET」
	4．Windowsフォーム・アプリケーションの開発

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）