リッチな UI の作成

Windows フォームの拡張機能を .NET アプリケーションに組み込む場合の基本原則

Chris Sells and Michael Weinhardt

翻訳元: Ground Rules for Building Enhanced Windows Forms Support into Your .NET App (英語)

この記事は、Visual Studio 2005 および .NET Framework 2.0 のプレリリース バージョンに基づいています。 この記事に含まれるすべての情報は、変更される可能性があります。

この記事で使用する技術: .NET Framework 2.0, Visual Studio 2005

この記事で取り上げる話題:

• 生産性向上に重点を置いた Visual Studio 2005 の改良
• リソースおよび設定管理の改善
• 柔軟なコントロールレイアウトと新しく追加されたストリップ コントロール
• データの連結

目次

1. プロジェクト設定
2. リソース管理の改善
3. 設定管理の改善
4. System.Windows.Forms.Form
5. フォームとコントロールのレイアウト
6. ストリップ コントロール
7. ToolStripContainer
8. ストリップ コントロールの設定管理
9. MaskedTextBox コントロール
10. データの連結
11. データ ソースへの連結
12. 新しいデータ連結コンポーネント
13. まとめ

我々が最後に Windows Forms 2.0 を検証したのは 2004 年の 5 月ですが、それ以降マイクロソフトによって多数の機能の名称変更、改善、および新規追加が行われました。 この記事で説明する機能は、Community Technology Preview December 2004 に基づいています。そのため、最終リリースでは一部の機能に変更が加えられる可能性があります (Windows フォームに関する前回の記事については、Craft a Rich UI for Your .NET App with Enhanced Windows Forms Support (英語) を参照してください)。

新機能の検証にあたり、出発点となるのが Windows フォーム プロジェクトです。最新のリリースでは、このプロジェクトに対しても変更が加えられています。 テンプレートから生成された新しい既定のレイアウトを図 1 に示します。

図 1 自動生成された既定の Window フォーム プロジェクト

新しいプロジェクト レイアウトでは、ウィザードによって生成された既定のフォームから不要なコードを取り除くことに重点が置かれています。C# では、以下に示す縮小バージョンのフォームが生成されます。

// Form1.cs
partial class Form1 : Form {
  public Form1() {
    InitializeComponent();
  }
}

Visual Basic では、さらにコードが短縮されたフォームが生成されます。

' Form1.vb
Public Class Form1
End Class

以前のバージョンの Visual Studio に慣れ親しんだユーザーであれば、InitializeComponent の実装がどこに行ったのか不思議に思うかもしれません。 InitializeComponent などデザイナが生成する Widows フォームのコードはすべて、図 1 に示す FormName.Designer.cs または FormName.Designer.vb と呼ばれる新しいファイルに移動されています。 クラスを 2 つの物理ファイルに分割するために、デザイナはパーシャル クラスという新しい言語サポートを使用しています。

' Form1.vb (開発者が管理するファイル)
Public Class Form1
End Class

' Form1.Designer.vb (デザイナが管理するファイル)
Partial Public Class Form1
    Inherits System.Windows.Forms.Form
  ...
  Private Sub InitializeComponent()
    ...
  End Sub
  ...
End Class

C# では、以下のファイルに分割されます。

// Form1.cs (開発者が管理するファイル)
partial class Form1 : Form {...}

// Form1.Designer.cs (デザイナが管理するファイル)
partial class Form1 {
  ...
  private void InitializeComponent() {...}
  ...
}

C# に慣れ親しんだユーザーであれば、アプリケーションのエントリ ポイント (静的 Main メソッド) がどこに行ったのかということについても不思議に思うでしょう。 Main は特定のクラスに関連付けられていないため、以下に示す Program.cs という独自のファイルに移動されています。

// Program.cs
static class Program {
  /// <summary>
  /// アプリケーションのメイン エントリ ポイントです。
  /// </summary>
  [STAThread]
  static void Main() {...}
}

Visual Basic 2005 の既定の設定では、アプリケーション開始時に Form1 が起動します。 必要に応じて、カスタマイズした Shared Sub Main をアプリケーションのエントリ ポイントとして指定できます。 このようにコードが分割されたことによって、開発者は特定の問題に対処するコードのみを記述すればよいことになります。 Windows フォーム デザイナの観点から見ると、InitializeComponent を分離することで、ユーザーが不注意にコードを変更してフォームに修正不可能なダメージを与えてしまうことを防止できます。

ページのトップへ

1. プロジェクト設定

Windows アプリケーションのプロジェクトには、プロジェクトの設定管理のためのフォルダも新しく追加されています。 これらのフォルダは、Visual Basic では My Project、C# では Configuration となります。 My Project については、Duncan Mackenzie が Navigate the .NET Framework and Your Projects with "My" (英語) で詳細に解説していますので、この記事では Configuration について簡単に説明します。 プロジェクトの [Configuration] フォルダをダブルクリックすると、図 2 の画面が表示されます。

図 2 C# Project Property エディタ

設定項目の大部分は前バージョンの Visual Studio と同じですが、[リソース] と [設定] が新たに追加されています。 モーダル ダイアログではなくデザイナ管理のエディタでプロジェクトの設定が公開されるため、Visual Studio 2005 の [ファイル] タブをシングル クリックするだけでプロジェクト設定を常時表示させることができます。そのため、プロジェクト設定に容易にアクセスできるようになっています。

ページのトップへ

2. リソース管理の改善

プロジェクトのリソースに加えられた改良はタブによるリソースの表示だけではありません。 リソース デザイナでは、初心者向けに強く求められてきた改良が行われました。その主な利点は、管理性の改善と WYSIWYG 機能の実現にあります。WYSIWYG 機能によって、図 3 に示すように、プロジェクトにどのようなリソースが含まれているのかデザイン時に確認できるようになっています。

図 3 Visual Studio 2005 リソース エディタ

新しいリソース デザイナでは、図 3 のドロップダウン リスト、クリップボードからのペースト、ドラッグ アンド ドロップなどさまざまな方法で新規ファイルおよび既存ファイルを追加できます。 Microsoft Word などのソースから文字列をドラッグすることもできます。そのため、文字列データが存在している場合には余分なタイプ入力を削減できます。

どの方法を使用するにせよ、追加したリソースは、「文字列」、「イメージ」、「テキスト ファイル」、「サウンド ファイル」などいずれかのカテゴリに自動的に追加されます。 もう 1 つのカテゴリの「その他｣には、デザイン時にコンポーネントによって定義されたシリアル化データなど、その他のリソースが格納されます。 [カテゴリ] リストの値を変更すると、各カテゴリの内容が表示されます。 各カテゴリはさらに細分化して表示できます。 たとえば、文字列以外のすべてのリソース タイプについては、[詳細]、[一覧]、および [縮小] 画面で表示できます。

表面化でリソース デザイナは、プロジェクトの [Configuration] フォルダ内に新たに追加された既定の Resources リソース (.resx) ファイルにリソース データを保存し、リスースに関するプログラミングを現在のリソース管理と同様関単に行えるようにさまざまな処理を行っています。 文字列リソースを取得する場合、以前のバージョンでは以下のようなコードを記述する必要がありました。

// リソースファイルから文字列リソースをロードします。
Assembly assem = Assembly.GetExecutingAssembly();
ResourceManager resman = new ResourceManager("MyApp.Resource1", assem);
string myStringResource = resman.GetString("MyString");

Visual Studio 2005 では、以下のように簡単かつ厳密に型指定された方法で文字列を取得できます。

// 厳密に型指定された文字列リソースをロードします。
string myString = Configuration.Resources.MyString;

リソース デザイナは、ユーザーが追加したすべてのリソースを厳密に型指定された静的 (共有) プロパティとして公開します。これらのプロパティは、リソース エディタが生成した Resources と呼ばれるマネージ クラスから取得されます。Resources クラスは ProjectName.Configuration 名前空間に格納されています。 プロジェクトを再ビルドするか、または .resx ファイルに関連付けられたカスタム ツールを実行して ResXFileCodeGenerator クラスを作成すると、これらのプロパティが生成されます。 アイコン、イメージ、サウンドなど、どんなリソース タイプについても文字列と同様に簡単に取得できます。

// あらゆる種類の厳密に型指定されたリソースをロードします。
Icon icon = Configuration.Resources.MyIcon;
Image image = Configuration.Resources.MyImage;
MemoryStream sound = new MemoryStream(Configuration.Resources.MySound);

現在、厳密に型指定されたリソース クラスを生成できるのは、Windows フォーム プロジェクトの既定のリソース ファイルのみです。 その他の .resx ファイルについても同様のサポートが必要な場合は、ResXFileCodeGenerator に対して、これらのファイルの Custom Tool プロパティを設定する必要があります。

ページのトップへ

3. 設定管理の改善

リソースと同様に設定にもカスタム エディタが用意されています。このエディタを使用すると、読み書き可能なユーザー設定または読み取り専用のアプリケーション設定のいずれかのスコープに対して型指定された設定を追加できます。 ユーザー設定は頻繁に変更されますが、データベース接続文字列などのアプリケーション設定がアプリケーションの配置後に変更されることは通常ありません。 アプリケーション設定はアプリケーション設定ファイル (applicationName.exe.config) に保存されます。 設定デザイナによるユーザー設定およびアプリケーション設定の設定方法を図 4 に示します。

図 4 Visual Studio 2005 設定エディタ

設定デザイナによって Settings クラス (ProjectName.Configuration 名前空間に格納されます) が生成されます。設定デザイナはこのクラスから指定された型のプロパティをインスタンスごとに表示します。 アプリケーション設定は読み取り専用プロパティとして表示されますが、ユーザー設定は読み書き可能プロパティとして表示されます。 いずれの場合でも、生成された静的 (共有) Value プロパティを使用して、プロパティの参照または更新をプログラマティカルに行うことができます。

// アプリケーション スコープの設定を参照します。
string appSetting = Configuration.Settings.Default.MyAppSetting;
// ユーザー スコープの設定を更新します。
Configuration.Settings.Default.MyUserSetting = "myNewUserSetting";

この機能によって、厳密に型指定されたリソースを使用する場合と同様に大きな利点を得ることができます。特に、アド ホックな設定処理が必要なときにこの機能が有効です。

ユーザーは、あるアプリケーション セッションの設定変更が次のセッションに継続されることを期待します。そのため、新規セッションの開始時に設定をロードして、セッションの終了時に設定を保存する必要があります。この処理の半分は自動的に実行されます。アプリケーション設定およびユーザー設定は、新規セッションで最初に使用されるときに自動的にロードされるからです。各セッションの終了時に設定を保存するためには、Save メソッドを一度呼び出す必要があります。このメソッドは Settings クラスを介して間接的にコードから使用できます。

void OptionsForm_FormClosing(object
sender, FormClosingEventArgs e) {
// 次回の使用に備えてユーザー設定を保存します。
Configuration.Settings.Default.Save();
}

このコードの適切な配置場所として FormClosing イベント ハンドラが考えられます。ユーザー設定は、ファイル システム内の Windows 所定の格納場所に、user.config というファイル名でユーザーごとに保存されます。ファイル名の user は、使用中のユーザーのプロファイル名を表しています。通常のシステムの場合、このファイルは以下のパスに保存されます。

c:\documents and settings\username\Local
Settings\Application Data\company name\product
name_hash\product version\

ユーザーが設定を不適切な値に変更してしまい、元の値が何であったかを思い出せないことがあります。幸いなことに、2 つの簡単なリカバリ オプションが用意されています。1 つは、最後に保存した設定に戻す手段をユーザーに提供することです。これは、以下に示すように、Settings オブジェクトの Reload メソッドを呼び出すことで実現できます。

void reloadSettingsButton_Click(object sender, EventArgs e) {
// 最後に保存したユーザー設定に戻します。
Configuration.Settings.Default.Reload();
}

このメソッドは、アプリケーションが起動時に使用した設定をロードします。ユーザー設定が認識不能なほどに変更された場合、設定デザイナに入力した初期値である既定のユーザー設定に戻すことができます。既定のユーザー設定を取得するには、Settings オブジェクトの Reset メソッドを呼び出します。

private void resetButton_Click(object sender, EventArgs e) {
// 既定のユーザー設定に戻します。
Configuration.Settings.Default.Reset();
}

user.config ファイルが削除された場合、次回のアプリケーション セッションで既定の設定値がロードされるという形でユーザー設定の管理が行われます。これは、Reset メソッドの呼び出しと同じです。設定サブシステムには、アップグレード サポート、設定プロファイル、カスタム設定プロバイダの作成などのより魅力的な機能が用意されています。カスタム設定プロバイダを使用すると、ユーザー設定を Web サービスなどに保存できます。

ページのトップへ

4. System.Windows.Forms.Form

System.Windows.Forms.Form に対して行われた機能拡張の全容についても検討する価値があります。System.Windows.Forms.Form は、Windows フォーム アプリケーションの開発において最上位に位置するクラスです。System.Windows.Forms.Form に対する変更は、.NET Framework 2.0 の主目的、つまり生産性の向上を目的として行われています。開発者の負担を減らすことを目的として追加された新しいメンバの中から主要なものを図 5 に示します。この中でも特に興味深いのがレイアウト機能の拡張です。

ページのトップへ

5. フォームとコントロールのレイアウト

フォームとコントロールのレイアウト管理のサポート拡充を目的として、System.Windows.Forms.Form および Windows フォーム デザイナに対する機能拡張が行われました。全体の処理が大幅に単純化されています。

Beta 1 スタイルのスナップライン

前回の記事では、スナップラインを使用すると矩形コントロールを非常に簡単に配置できることについて説明しました。デザイナには 3 番目のスナップ機能としてテキスト基準線を表す赤いスナップラインがあり、この線に沿ってコントロールを配置できるようになっています。上端、テキスト基準線、および下端を表す動作中のスナップラインを図 6 に示します。

図 6 配置

パディングとマージン

スナップラインを使用すると、コントロールをフォームにドラッグしたときに、水平線および垂直線に合わせて簡単に配置できます。各コントロールを適切に配置するだけでなく、コントロール間に適当なスペースを空ける必要があります。この機能は、Padding および Margin という新しいプロパティによって実現されます。パディングとは、フォームの縁から内側へのピクセル単位の距離、または子コントロール (およびテキスト、イメージなど) が侵入できないコントロールのクライアント領域のことです。マージンとは、コントロールの縁から外側へのピクセル単位の距離のことであり、その中に他のコントロールが侵入することはできません。コントロールをフォームにドラッグすると、コントロールとフォームの距離がパディングとマージン (関連がある場合) の合計に等しくなったとき、Windows フォーム デザイナによってコントロールとフォームの間に破線が表示されます。Label コントロールと TextBox コントロールの間の破線を図 6 に示します。マージンとパディングによるコントロール間の適切なスペースの設定方法を図 7 に示します。Padding プロパティおよび Margin プロパティは、すべての縁に対して一括で指定することもできますし、縁ごとに個別に指定することもできます。

図 7 マージンとパディング

複雑なレイアウト シナリオ

1 つ以上のコントロールを含むサイズ調整可能なダイアログなどより複雑なレイアウト シナリオの場合は、精巧なレイアウト要件に対処するための特別なレイアウト コントロールの作成基盤となる高度なレイアウト エンジンが必要になります。Windows Form 2.0 には、TableLayoutPanel および FlowLayoutPanel という HTML スタイルのレイアウト機能を取り入れた 2 つのレイアウト コントロールが用意されています。両コントロールはパネル形式のコントロールで、他のコントロールを配置できるように設計されています。同時に、デザイン時および実行時において、各コントロールの特定のレイアウトを適用できます。

TableLayoutPanel

TableLayoutPanel を使用すると、サイズの自動調整が可能な行と列を定義できます。自動調整の方法には、AutoSize、Percent、Absolute のいずれかを指定できます。Windows フォーム デザイナを使用すると、行や列を結合したり、物理サイズを再調整したりすることもできます。各セルに配置可能なコントロールは 1 つだけで、コントロールの位置はドッキングとアンカリングによって決定されます。TableLayoutPanel の使用例を図 8 に示します。

図 8 TableLayoutPanel コントロール

図 8 には、[OK] ボタンと [Cancel] ボタンも表示されています。これらのボタンはネストされた TableLayoutPanel に配置されています。TableLayoutPanel の各セルに配置可能なコントロールは 1 つだけですので、テーブルのネストは有効な活用法となる場合があります。逆に、結合された行や列に対して TableLayoutPanel の機能を適用することもできます。

FlowLayoutPanel

表形式のレイアウトが要件を満たさない場合は、FlowLayoutPanel がより適切な選択肢となることがあります。特に、フォームやコントロールのリサイズを HTML Web ページと同じ方式で行いたい場合にこのコントロールが有効です。FlowLayoutPanel の FlowDirection プロパティを、LeftToRight、TopDown、RightToLeft、または BottomUp のいずれかに設定することによって、フォームのリサイズ時に FlowLayoutPanel が移動する方向を指定できます。

FlowLayoutPanel を縮小し過ぎると、Web ページと同様、パネル内のコントロールがそれ以上移動できなくなります。その場合、FlowLayoutPanel の上下の枠、左右の枠、またはその両方によって、各コントロールの一部またはすべてが隠されることになります。AutoScroll プロパティを True に設定すると、必要に応じて垂直および水平スクロールバーが表示されます。

ページのトップへ

6. ストリップ コントロール

レイアウト パネルに加えて、前回の記事で紹介した新しいコントロールの一部にも大きな改良が加えられました。その中で最も大きな変更点の 1 つは、映画のグレムリンを思い起こさせます。マイクロソフトの誰かが真夜中過ぎに WinBar に餌を与えたに違いありません。なぜなら、WinBar が、MenuStrip、ToolStrip、StatusStrip、ContextMenuStrip などを含む完全なストリップ コントロール スイートへと増殖したからです (図 9)。

図 9 ストリップ コントロール

新しいストリップ コントロールは、MainMenu、ToolBar、StatusBar、および ContextMenu を改良したものです。主な改良点として以下が挙げられます。

• 全ストリップ コントロールに対して一貫性のある API が用意されています。
• デザイン時におけるエクスペリエンスが向上しています。
• 隣接するコントロールを互いに再配置できます。また、ホストとなるフォームのクライアント領域において、上下左右に再配置することもできます。
• Office 2003 および Windows のテーマに沿った最新の外観を備えています。
• ドロップダウン リスト、ラベル、メニュー、テキストボックスなど、多数のコントロールを内部に配置できます。
• レンダリング機能が用意されており、描画用のカスタム コードを簡単に記述できます。

Visual Studio の既定のツールボックスには、MainMenu、ToolBar、StatusBar、および ContextMenu は含まれていませんが、下位互換性維持のため、.NET Framework には依然として含まれています。もちろん、ストリップ コントロールはツールボックスに含まれているため、フォームに簡単にドラッグできます。デザイナを使用すると、さまざまなコントロールを各ストリップ コントロールに追加できます (図 10 参照)。

図 10 ストリップ コントロールに配置されたコントロール

ストリップ コントロールには、柔軟な設定オプションが多数用意されています。Property Browser からは、ストリップ コントロールおよびストリップ アイテム コントロールのすべての設定を行うことができます。一方、スマート タグを使用すると、両コントロールの主要なプロパティを設定できます。これらだけでは不十分な場合は、ストリップ アイテムの追加、変更、および削除をビジュアル デザイン画面上で直接行うこともできますし、[Edit Items] ダイアログから行うこともできます。[Edit Items] ダイアログには、Property Browser およびスマート タグの両者から必要に応じてアクセスできます。

MenuStrip と ToolStrip には Insert Standard Items オプションが用意されています。このオプションを使用すると、「開く」、「保存」、「別名で保存」、「切り取り」、「コピー」、「貼り付け」など代表的なコマンド用のストリップ アイテムを事前に作成できます。適用可能な設定オプションの中から主要なものを図 11 に示します。

図 11 ストリップ コントロールの主要な設定プロパティ

ストリップ アイテム コントロールには、Enabled、Visible、Checked、BorderStyle などの標準プロパティに加えて、図 12 に示すユニークなプロパティが用意されています。

図 12 ストリップ アイテム コントロールの主要な設定プロパティ

ページのトップへ

7. ToolStripContainer

既定では、ストリップ コントロールはデザイン時および実行時に配置された場所から移動することはありません。ただし、ストリップ コントロールの追加機能を使用すると、開発者およびユーザーがストリップ コントロールをフォームの一方の縁から別の縁に移動できるようになります。この機能を用意する必要がある場合は、ToolStripContainer という新しいコントロールを使用できます。ToolStripContainer は 4 つのツール ストリップ パネルから構成されています。図 13 の青色の部分がこのツール ストリップ パネルを表しており、灰色で表示されているコンテンツ パネルを囲んでいます。

図 13 ツール ストリップ

コンテンツ パネルには、フォームの作成に通常使用するコントロールを配置します。ツール ストリップ パネルは、ストリップ コントロールの配置用に設計されています。ツール ストリップ パネルの縁に表示されている 4 つのボタンを使用すると、各ツール ストリップ パネルの高さや幅をツール ストリップ コントロールのサイズに応じて拡張したり、縮小したりできます。デザイン時にストリップ コントロールをツール ストリップ パネルにドラッグすると、それらのコントロールは水平または垂直方向に互いに重ねられます。コントロールの場所をスタック内で変更するには、単にそのコントロールを目的の位置にドラッグするだけです。スタック内におけるコントロールの位置の保存と適用には Z-Order を使用します。Z-Order を高く設定すればするほど、そのストリップ コントロールはフォームの縁に近づきます。

実行時にフォームがロードされると、ストリップ コントロールが既定のツール ストリップ パネルに表示されます。Figure 14 は、ユーザーがその後でストリップ コントロールをフォームの一方の縁から別の縁にドラッグできることを示しています。ただし、この機能を実現するためには、ToolStripContainer を使用する必要があります。

図 14 ストリップのドラッグ

ストリップ コントロールが他のツール ストリップ パネルに再配置されると、ツール ストリップ コンテナが移動して、コントロール用の場所が空けられます。この利点は、ツール ストリップ コンテナ内のすべてのコントロールも同時に移動するため、コントロールを手作業で再配置する手間が省けるということです。

ページのトップへ

8. ストリップ コントロールの設定管理

配置やストリップ アイテムの並べ替えなど、実行時にはストリップ コントロールに対してさまざまな操作が行われます。 これらはユーザーの変更なので、優れたアプリケーションを作成するためには、これらの変更内容をセッション間で保持する必要があります。 ストリップ コントロールには、SaveSettings および SettingsKey という変更内容の保持を目的とした 2 つのプロパティが用意されています。 SaveSettings はブール型のプロパティであり、既定値は False に設定されています。 開発者が True に変更すると、位置、場所、サイズ、ストリップ アイテム コントロールの配置など、ストリップ コントロールの値が先述のユーザー設定サブシステムに保存されます。 SettingsKey は、設定ファイルに保存されている値セットを特定するための文字列値です。

FormName.StripControlName

必要に応じてこの値を変更できますが、いったん有効にすると、ユーザー設定から値セットが自動的に取り出され、ストリップ コントロールに適用されます。その結果、アプリケーションがロードされるたびに、ストリップ コントロールが正しい位置に配置されることになります。 現時点でこの機能を提供しているのはストリップ コントロールとストリップ コントロール アイテムだけですが、独自のカスタム コントロールに設定機能を追加することができます。

ページのトップへ

9. MaskedTextBox コントロール

もう 1 つの追加コントロールである MaskedTextBox はデータの入力に使用します。デザイン時にマスク文字を使用することによって、入力するデータの型と形式を指定できます。たとえば、マスク文字に "9" を指定すると、ユーザーはスペースまたは 0 ～ 9 の任意の数字を入力できます。"0" を指定すると、数値のみの入力が可能となります。もちろん、数字、文字、句読点、および空白に対応するさまざまなマスク文字があります。詳細については、Visual Studio の新しいマニュアルを参照してください。開発者は、MaskedTextBox の Mask プロパティに適切なマスク値を設定することでマスクを作成できます。図 15 に示す Input Mask エディタを使用すると、既存の共通マスクを使用するか、または独自のマスクを作成するかを選択できます。また、設定したマスクを動的に検証することもできます。

図 15 Input Mask エディタ

括弧、ハイフン、スペースなどの非マスク文字はリテラルとして扱われ、実行時に表示されます。これにより、ユーザーは入力データの型についてより強力な視覚的ヒントを得ることができます。一方、マスク文字は実行時にすべてプロンプト文字 (既定ではアンダーライン) に置き換えられ、データの入力位置がハイライト表示されます。実行時にプロンプト文字が表示されるのは、MaskedTextBox にフォーカスがある場合のみです。

MaskedTextBox にはさまざまなプロパティが用意されています (図 16 参照)。これは高度な設定が可能なコントロールであり、この設定機能を活用することで、ユーザーがより多くの情報に基づいてデータ入力を行うことができます。

図 16 MaskedTextBox の主要プロパティ

ページのトップへ

10. データの連結

前回の記事では、データ連結に関する箇所において、GridView および DataContainer という 2 つのコントロールについて検証しました。 WinBar と同様、これら 2 つのコントロールに対しても大幅な変更が加えられています。 GridView は現在 DataGridView と呼ばれており、DataContainer はBindingSource および BindingNavigator という 2 つの新しいコントロールに分割されています。 実際はデータ連結サブシステム全体に対してさまざまな変更が加えられています。その中から最も注目すべき変更点について検証してみます。

図 17 データ ソース

データ連結にはデータ ソースが必要です。 Visual Studio 2005 では、データ ソースをこれまでよりもはるかに関単に作成できます。最も簡単な方法は、[データ]-[新しいデータ ソースの追加] を選択することです。これによって、[データ ソース構成] ウィザードが開きます。 選択可能なデータ ソースは以前よりも幾分拡張されており、データベース (予想通り)、Web サービス、およびその他のオブジェクトから選ぶことができます。 データベースからデータ ソースを作成する場合、型指定された新しい DataSet がプロジェクトに追加されるだけでなく、新たに追加された [データ ソース] ツール ウィンドウ ([データ]-[データ ソースの表示]) からそのデータ ソースを参照できます(図 17 参照)。

[データ ソース] ツール ウィンドウを使用すると、型指定された DataSet デザイナを使用したデータ ソースの編集、選択したデータ ソースの再設定、既存のデータ ソースの更新、または新規データ ソース追加を行うことができます。 これらの方法を使用してデータ ソースの作成を行っていない場合、DataGridView などのコントロールをフォームにドロップすると、既存のデータ ソースの選択または作成を促すプロンプトが表示されます。

ページのトップへ

11. データ ソースへの連結

データ ソースの作成に複数の方法があるのと同様に、コントロールとデータ ソースの連結にも複数の方法があります。1 つは、[データ ソース] ツール ウィンドウからテーブルとフィールドを直接フォームにドラッグすることです。この単純な操作により、以下に示す重要な変更が表面化でフォームに加えられます。

• コントロールの連結対象となる型指定された DataSet コンポーネントが追加されます。
• 型指定されたデータ アダプタが追加されます。データ ソースがデータベースの場合、データの読み込みと更新にこのデータ アダプタが役立ちます。
• データ ソースを表示する BindingSource コンポーネントが追加されます (以下で説明します)。
• データ参照用の BindingNavigator コンポーネントがフォームに追加されます (以下で説明します)。
• フォームの Load イベント ハンドラが作成または更新され、データ ソースからデータが自動的に読み込まれます。
• 当然ですが、コントロールが追加されて、ドラッグしたフィールドまたはテーブルに自動的に連結されます。

デザイナは作成および連結するコントロールの種類をどのようにして決定するのでしょうか。図 17 では、Employees テーブルおよび各フィールドの横にアイコンが表示されています。このアイコンは、テーブルまたはフィールドがフォームにドラッグされたときに作成されるコントロールの種類を表しています。[データ ソース] ツール ウィンドウからコントロールの種類を設定する方法を図 18 に示します。

図 18 コントロールの種類を設定

ほとんどのオプションは自明です。[なし] を選択すると、テーブルおよびフィールドをフォーム上にドラッグできなくなります。[カスタマイズ...] を選択すると、各データ型に対して作成可能なコントロールまたはテーブルの表示スタイルを指定できます。フィールドをフォーム上にドラッグすると、指定した種類のコントロールと Label コントロールが作成されます。ソースのフィールド名の書式が適切であれば、デザイナは単純なヒューリスティックを使用してそのフィールド名を変換します。変換後の文字列には所定の位置にスペースが挿入されており、また大文字と小文字が正しく組み合わされています。この文字列は新しく作成された Label コントロールに表示されます。たとえば、"EmployeeID" は "EmployeeID:" となります。

ページのトップへ

12. 新しいデータ連結コンポーネント

データ ソースを DataGridView としてフォームにドラッグすると、BindingSource および BindingNavigator という 2つのコンポーネントも同時にフォームに追加されます。データ連結コントロールとデータ ソースの間には BindingManager が存在しています。BindingManager が実行する処理は以下のとおりです。

• 連結コントロールとデータ ソースとの連結を管理します。
• 元となるデータ ソースが変更されたとき、連結コントロールのデータを更新して最新の状態に保ちます (逆の場合も同様です)。
• 現在のレコード (または カレンシ) を追跡します。

DataGridView などの複合データ連結コントロールは、BindingManager にアクセスしてこれらの機能を実行する方法について認識しています。ただし、TextBox の Text プロパティとリストのデータ フィールドとの連結など、単純データ連結を使用するシナリオでは、これらの機能は利用できません。その代わりに、独自のコードを手作業で作成することで、BindingManager へのアクセスとのその利用が可能になります。たとえば、データベース テーブルなどの表形式のデータ ソースで次のレコードに移動する場合は、以下のようなコードを記述します。

void nextButton_Click(object sender, 
  EventArgs e) {
  // 次のレコードに移動します。
  Binding binding = nameTextBox.DataBindings["Text"];
  BindingManagerBase manager = binding.BindingManagerBase;
  manager.Position = manager.Position + 1;
}

こうした手間を省くため、BindingSource が作成されました。BindingSource は連結マネージャのラッパーであり、単一のコンポーネントに基づくインターフェイスを介して連結マネージャを公開します。BindingSource をデータ ソースに連結する場合は、その他の複合連結コントロールと同様に、DataSource プロパティと DataMember プロパティを設定します。これによって、BindingSource が連結マネージャにアクセスできるようになるため、BindingSource のインターフェイスを介して連結マネージャの機能をより関単に利用できるようになります。BindingSource は、基本データ ソースによって公開されるフィールドをリフレクションを使用して決定し、独自の IBindingList 実装によってこれらのフィールドを公開します。これによって、TextBox コントロール (またはどのコントロールでも) の Text プロパティ (またはどのプロパティでも) を BindingSource に直接連結できるようになります。この機能を利用することで、上記のサンプル コードを以下に示すわずか 1 行のコードに短縮できます。

void nextButton_Click(object sender, EventArgs e) {
  // 次のレコードに移動します。
  this.employeesBindingSource.MoveNext();
}

図 19 Binding Navigator

VCR スタイルのナビゲーションが必要な場合は、Figure 19 に示す BindingNavigator コンポーネントを使用することで、コードをまったく記述する必要がなくなります。BindingNavigator は特殊化されたストリップ コントロールであり、BindingSource プロパティを介して BindingSource に連結します。BindingSource は、データ ソース ナビゲーションの管理を目的として、既定の BindingNavigator ボタンによって使用されます。BindingNavigator はストリップ コントロールであるため、その再設定を行う場合は、ツール ストリップ アイテムの既定の設定を変更するか、または連結データの読み込みや保存など新しいツール ストリップ アイテムを追加します。

ページのトップへ

13. まとめ

この記事では、.NET Framework 2.0 および Visual Studio 2005 の December 2004 CTP リリースにおいて、Windows フォームに追加された新機能と拡張機能の一部について説明しました。リソースおよびアプリケーションの設定管理の改良、厳密に型指定されたインターフェイスの生成など、Visual Studio 2005 の新機能についてまず検証しました。次に、System.Windows.Forms.Form クラスに対する、生産性の向上に焦点を当てた変更について調べました。デザイン時のエクスペリエンスについても、さまざまなレイアウト機能をはじめとして、生産性向上を目的とした機能拡張が行われています。MaskedTextBox コントロールなど、新たに追加された興味深いストリップ コントロールもまた生産性の向上に寄与しています。さらに、DataGridView、BindingSource、BindingNavigator など、データ連結の基盤全体に対して多数の改良が行われています。

Windows Forms 2.0 の生産性や機能は、.NET Framework 1.x で提供された以前のバージョンと比べてはるかに向上しています。結論として、今後数年間は Windows Forms 2.0 が Windows フォームの開発プラットフォームとして利用される可能性が高いと考えられます。

Chris Sells MSDN オンラインのコンテンツ戦略担当者であり、現在は Windows の次期バージョンである Longhorn や スマート クライアント に関する仕事に従事しています。詳細については、www.sellsbrothers.com (英語) を参照してください。

Michael Weinhardt 現在は Chris Sells の著書『Windows Forms Programming in C#』の共同改定作業、および MSDN オンラインの月次コラム『Wonders of Windows Forms』の執筆に取り組んでいます。詳細については、www.mikedub.net を参照してください。

この記事は、MSDN マガジン - 2005 年 5 月号からの翻訳です。