特集

.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によって自動生成されたコード。
  [ファイルを開く]ダイアログを表示し、指定されたファイルから画像を読み込んで表示するコード。
  メイン・フォームである自分自身を閉じ、アプリケーションを終了させるコード。

 アプリケーションをビルドして実行すれば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の世界に慣れておくのも悪くはないだろう。End of Article

 

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


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間