スマートクライアント

[アーティクル]
10/20/2021

強化された Windows フォームサポートによる .NET アプリケーションのリッチな UI の作成

Chris Sells and Michael Weinhardt

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

Windows フォームコントロールの新規事項
設定、およびリソースの管理
レイアウト、サイズ変更、および拡大縮小
データバインディング
ClickOnce 配置

この記事で使用する技術:

Windows Forms、Visual Studio、.NET Framework 2.0

翻訳元: Craft A Rich UI For Your .NET App With Enhanced Windows Forms Support (英語)

Windows フォームプロジェクト
コード分離
リソース管理の改善
設定管理の改善
System.Windows.Forms.Form
スナップライン、Margins、および Padding
自動的なサイズ変更と拡大縮小
TableLayoutPanel と FlowLayoutPanel
コントロールとコンポーネント
MaskedTextBox コントロール
Web ブラウザ
BackgroundWorker コンポーネント

オートコンプリート
ストリップコントロール
ストリップコンテナ
データバインディング
BindingSource
DataGridView
ドラッグアンドドロップによるデータバインディング
ClickOnce 配置
発行
セキュリティ
まとめ

Windows Forms 2.0 は、これまでのどのような Windows アプリケーション開発プラットフォームよりも強力です。大幅に機能強化された Microsoft .NET Framework、多くの新しいデザイナとの統合が一層進められた Visual Studio、統一データバインディングモデル、さらに、Web スタイルでの配置のための ClickOnce など、広範囲にわたって大きく改善されています。

System.Windows.Forms 名前空間は、Windows フォームを構成するテクノロジの中心であり、これにも大幅な改善が行われています。名前空間の使用可能な表面の部分、つまり、パブリック型 (クラス、および列挙体) は、.NET Framework 1.1 から約 134% 増加しています。新しく 446 個のパブリック型が追加され、113 個の既存の型が新しいメンバ、および値で更新されました。また、218 個の型が以前の名前空間から引き継がれ、削除された型はありません。つまり、今回は、メジャーリリースとなっています。実際に、メジャーすぎるために、ここではすべてを説明できません。図 1 には、概要を示しています。本当に、多くの機能があります。新しく Windows フォームプロジェクトを作成する場合には、これらのすべてを活用できます。

図 1 Windows Forms 2.0 の新機能

機能	改良点
フォーム	Form クラスの強化。より強力な検証インフラストラクチャ。新しいフォームプロジェクトウィザード。
レイアウト	スナップラインが表示されるレイアウトモード。位置や間隔の自動調整のための Margin、および Padding のサポート。Web スタイルと同様のフローレイアウト、およびテーブルレイアウト、あるいは分割を可能にする専用コントロール。フォームの自動的なサイズ変更。さまざまな画面の DPI に合わせてのフォーム、およびコントロールの自動的な拡大縮小。
描画	ネイティブスクリーンダンプのサポート。TextRenderer による GDI ベースのテキスト表示。自動、および手動でのダブルバッファリングの強化。
印刷	印刷に固有のさまざまイベント、イベント引数、列挙体、ダイアログ、および汎用印刷クラスなどによる印刷サポートの改善。
コンポーネント/コントロール	新しいコンポーネント、およびコントロールのホスト。たとえば、MaskedTextBox、WebBrowser、SoundPlayer。また、メニューバー、ツールバー、ステータスバー、およびコンテキストメニューを対象とする、Office 2003 スタイルのツールストリップコントロールなど。大部分のコントロール、およびコンポーネントにおける、構成をすばやく行うためのスマートタグのサポート。
デザイン時の統合	いくつかの新しいデザイン時属性。デザイン時のコンポーネント初期化サポートの更新。カスタムコンポーネントでのデザイン時のスマートタグの統合。
リソース	アプリケーションリソースの埋め込み、およびリンクの両方の機能。厳密に型指定されたラッパークラスによるアプリケーションリソースの提供。WinForms プロジェクトの既定でのプロジェクト単位のリソースサポート。右から左へのレンダリングの完全サポート。
アプリケーション	Visual Basic ランタイムによる、シングルインスタンス、およびスプラッシュスクリーンのサポート
設定	厳密に型指定されたラッパークラスによる設定の提供。ロード、更新、保存、およびバージョン管理の設定のための豊富なプログラム的サポート。設定の安全な永続化 (部分信頼コードの実行のため)。Windows フォームプロジェクトの既定でのプロジェクト単位での設定のサポート。
データバインディング	異種データソースの一体化。デザイン時サポートの強化。優れたバインディング、およびグリッド UI 機能を備える DataGridView コントロール。ツールストリップスタイル (VCR スタイル) ナビゲーションのための BindingNavigator。Windows フォーム検証との緊密な統合。
マルチスレッド化ユーザーインターフェイス	BackgroundWorker コンポーネント。非同期 Web サービスメソッド呼び出しの簡略化。
ClickOnce 配置	アプリケーションの自動的な発行、配布、インストール。緊密な Visual Studio 統合、および構成サポート。信頼された配置。スマートクライアントのサポート。

1. Windows フォームプロジェクト

C#、あるいは Visual Basic のどちらを使用する場合でも、Windows フォームプロジェクトを新規に作成すると、まず、Visual Studio Windows アプリケーションプロジェクトウィザードによって既定のプロジェクト構造が生成されます。図 2 に、この構造を示します。この構造も更新されており、プロジェクトの強化点がいくつ反映されています。それらについて説明します。

図 2 Windows フォームプロジェクトの構造
図 2 Windows フォームプロジェクトの構造

ページのトップへ

2. コード分離

既定のプロジェクト構造を新しくした目的の 1 つは、既定の Form1 からコードを取り除くことでした。これにより、実装が削減され、C# では次のようになります。

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

Visual Basic では、さらに削減されています。

' Form1.vb
Public Class Form1
End Class

InitializeComponent は、どこへ行ったのか疑問に思うことでしょう。Windows Forms 2.0 では、InitializeComponent メソッドなどのデザイナ管理フォームコードは、新しいファイル FormName.Designer.cs、あるいは FormName.Designer.vb に永続化されます。この分離は、開発者のコードと Windows フォームデザイナのコードが混在するのを避けることを目的とし、C#、および Visual Basic の両方の言語で新しくサポートされるようになったパーシャルクラスによって実現されています。以下に、コードのサンプルを示します。

// Form1.cs (開発者管理)
public partial class Form1 : Form { ... }

// Form1.Designer.cs (デザイナ管理)
partial class Form1 {
    ...
    void InitializeComponent() { ... }
    ...
}

Visual Basic では、次のようになります。

' Form1.vb (開発者管理)
Public Class Form1
End Class

' Form1.Designer.vb (デザイナ管理)
Partial Class Form1
       Inherits System.Windows.Forms.Form
    ...
    Private Sub InitializeComponent()
        ...
    End Sub
    ...
End Class

C# 開発者は、ウィザード生成の static Main メソッドがどこに行ったのかも疑問に思うことでしょう。Main は、フォームのスコープではなく、アプリケーションのスコープであるので、次のように、独自のファイル Program.cs に移動されています。

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

Visual Basic プロジェクトは、アプリケーションが起動したときに、既定で、Form1 が開始するように構成されています。必要に応じて、カスタム Shared Sub Main エントリポイントを使用することができます。コード分離の結果、開発者は、開発者としての目的を達成するのに必要なコードのみに専念することができるようになります。

ページのトップへ

3. リソース管理の改善

Windows Forms 2.0 のプログラミングをより簡単にするために、IDE 自体も更新されています。Visual Studio リソースエディタには、必要とされる変更が大幅に行われました。主な利点は、改善された管理、およびリソースが実際にどのように見えるかを確認する機能です。図 3 にリソースエディタを示します。

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

新しいリソースエディタでは、さまざまな方法で新規、および既存のファイルを追加できます。図 3 では、ドロップダウンリストを使用しています。この他に、クリップボードや、ドラッグアンドドロップなども使用できます。どの方法を使用した場合でも、リソースは、文字列、イメージ、アイコン、ファイル、およびオーディオのいずれかのカテゴリに自動的に分類されます。この他に、デザイン時データのコンポーネント定義シリアル化などのリソースデータ用に、その他というカテゴリも存在します。リソースエディタの左上のドロップダウンリストを選択して、カテゴリごとに表示します。各カテゴリでは、それに含まれるリソースの種類に合わせた専用のビューが提供されています。たとえば、文字列以外のリソースでは、Windows エクスプローラと同様に、表示を、詳細、一覧、あるいは縮小のいずれかにすることができます。

もう 1 つの重要な改善点は、リソースを埋め込むか、あるいはリンクするかのどちらかを指定できる機能です。プロパティエディタを使用してプロジェクトに追加され、埋め込まれたリソースは、プロジェクト単位のリソース (.resx) ファイルに保管されます。リンクリソース (文字列以外のリソースの既定) は、Visual Studio がプロジェクトシステムの外のファイルを参照すること意味します。これにより、別の人がリソースデータ (グラフィックや音声など) を管理することが簡単になり、開発者は、アプリケーションの構築という自身の作業に注力することができます。もちろん、Visual Studio は、この後の作業でも開発者の期待に応えます。

以前の Windows Forms 1.x で、コードから文字列のリソースを取得するために必要だった作業を思い出してみましょう。

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

Windows Forms 2.0 では、次のように、簡略化され、厳密に型指定した方法が可能です。

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

新しい Windows フォームは、Resources (ProjectName.Properties 名前空間に位置します) クラスを生成します。このクラスは、厳密に型指定した static (shared) プロパティを提供します。これにより、アイコン、イメージ、およびオーディオなど、どのような種類のリソースでも、文字列のように簡単にコードで取得できます。

// すべての種類を厳密に型を指定したリソース
string myString = Properties.Resources.MyString;
Icon myIcon = Properties.Resources.MyIcon;
Image myImage = Properties.Resources.MyImage;
UnmanagedMemoryStream mySound = Properties.Resources.MySound;

プロジェクトに、他の .resx ファイルを追加した場合は、厳密に型指定したラッパークラスも生成されます。

ページのトップへ

4. 設定管理の改善

プロジェクトのプロパティページから、新しく、設定エディタが使用できるようになりました。ここから、アプリケーションとユーザーという、2 つのスコープのいずれかで、設定を追加することができます。アプリケーション設定とは、データベース接続文字列、および URL などであり、アプリケーションのインストール後に変更されない永続的な設定です。ユーザー設定は、[ツール] の [オプション] メニューに見られるような設定であり、インストール後にユーザーが変更できる既定の設定です。図 4 に、設定エディタの動作を示します。

図 4 Visual Studio 設定エディタ

設定エディタは、アプリケーション設定、およびユーザー設定の両方を、1 つのアプリケーションの構成ファイル (ApplicationName.exe.config) で配置します。また、リソースと同様に、Windows フォームは、厳密に型指定したラッパークラスを、ProjectName.Properties 名前空間に生成します。アプリケーション設定は、読み取り専用プロパティとして実装されます。一方、ユーザー設定は、読み取り、および書き込み可能プロパティとして実装されます。どちらも、生成された static (shared) Default プロパティから、プログラムで、検査、あるいは更新できます。

// アプリケーションスコープの設定の検査
string myAppSetting = Properties.Settings.Default.MyApplicationSetting;

// ユーザースコープの設定の更新
Properties.Settings.Default.MyUserSetting = "myNewUserSettingValue";

ユーザーが設定を変更したときに、アプリケーションの次回のセッションでもその変更が適用されるようにする場合は、ユーザー設定の変更を、セッションが終了するときに保管し、次のセッションが開始するときに再ロードする必要があります。各セッションの開始時には、ユーザー設定、およびアプリケーション設定の両方が自動的にロードされます。ただし、ユーザー設定の保管は、セッションの終了時に手動で行う必要があります。保存するには、次のように、生成された Settings クラスで提供される Save メソッドを呼び出します。

void OptionsForm_FormClosing(object sender, FormClosingEventArgs e) {
    // 次回のために設定を保管します。
    Properties.Settings.Default.Save();
}

アプリケーション設定は、読み取り専用ですが、ユーザー設定はそうではありません。ユーザー設定は、アプリケーション構成ファイルとは別のファイルに保存される必要があります。このため、Windows フォームは、ユーザー設定を user.config に永続化します。このファイルは、Windows ロゴに準拠したファイルシステムの、ユーザーに関連付けられている場所に置かれます。ファイルのパスは、ローミングが可能であるかどうかなど、特定の条件によって異なります。スタンドアロンアプリケーションでは、次の場所が使用されます。

%InstallRoot%\Documents and Settings\UserName\
    Local Settings\Application Data\ProductName\
        ApplicationName.exe_Url_UrlHash\AssemblyVersionNumber

また、ユーザーが、間違って設定を変更し、前の設定がわからなくなり困るようなことがあります。このような場合のために、最後に保存されていた設定に戻すメカニズムを提供することができます。これには、次のように、Settings オブジェクトの Reload メソッドを呼び出します。

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

さらに、ユーザー設定を完全に戻すために、アプリケーションが配置された当初の設定、つまり設定エディタに入力した値に戻すこともできます。この設定を取得するには、Settings オブジェクトの Reset メソッドを呼び出す必要があります。

void resetButton_Click(object sender, EventArgs e) {
    // 既定でインストールされたユーザー設定に戻します。
    Properties.Settings.Default.Reset();
}

この設定は、user.config ファイルが削除された場合に、アプリケーションの次のセッションでロードされるユーザー設定の既定値として使用するために管理されています。

ページのトップへ

5. System.Windows.Forms.Form

Visual Studio は、Windows フォームアプリケーション構築のための第一のツールであり、System.Windows.Forms.Form は、その第一のクラスです。このクラスも、更新されています。図 5 に示すような新規メンバが追加されています。最も注目すべき新規メンバは、レイアウトを扱うメンバです。

図 5 System.Windows.Forms.Form の重要な強化点

メンバ	型	説明
FormClosing、	イベント	これらは、Closing、および Closed の後継であり、フォームが閉じるときの FormClosed を処理するイベントです。どちらも、コンテキストをより詳細に提供するようになりました。たとえば、シャットダウンの要因が、ユーザー、タスクマネージャ、Windows シャットダウンなどのいずれであるかがわかります。Closing、および Closed も、下位互換の目的のためにサポートされています。
ResizeBegin、ResizeEnd	イベント	ResizeBegin および ResizeEnd は、フォームのサイズ変更に関してより詳細な操作を可能にします。
Shown	イベント	フォームが最初にオープンされたときに発生します (Activate は、フォームがアクティブになるたびに発生します)。
Validate	メソッド	フォーム上のすべてのコントロールを検証します。
ValidateChildren	メソッド	フォーム内で、ValidationConstraints 引数での指定に一致する子コントロールを検証します。引数では、使用可能である、選択可能である、表示されている、フォームの直接の子である、および Tab キーで移動できる、などを指定できます。
DrawToBitmap	メソッド	フォーム全体、あるいは一部の、ビットマップへのスクリーンダンプを可能にします。
AutoValidate	プロパティ	AutoValidate では、フォームの検証の動作を、AutoValidate 列挙体を使用して指定することができます。このために、列挙体には、4 つの値、Disable、EnableAllowFocusChange、EnablePreventFocusChange、および Inherit が提供されています。Disable は、コントロールの検証を無効にします。EnableAllowFocusChange は、検証が失敗したコントロールからフォーカスが移動することを許可します。EnablePreventFocusChange は、これを許可しません。Inherit は、コントロールが、自身のホストコントロール、あるいはフォームの自動検証の動作を引き継ぐようにします。
RightToLeftLayout	プロパティ	RightToLeft プロパティを True に設定した場合は、コントロールのテキストが、最初とは反対に表示されます。RightToLeftLayout を True にした場合は、フォーム上のコントロール自体のレイアウトが変わります。システムメニュー、および最大化や最小化、閉じるボタンなどのフォームの部品も、同様に変更されます。

ページのトップへ

6. スナップライン、Margins、および Padding

スナップラインは、コントロールをフォームにドロップして、ドラッグするときに使用できます。フォームでコントロールをドラッグすると、スナップラインの機能が、1 つ、あるいは複数の線を表示して、縦横の両方向で、近くにある別のコントロールとテキストのベースライン、およびテキストの余白が一致するように、コントロールの整列を誘導します (図 6 を参照)。

図 6 スナップライン
図 6 スナップライン

コントロールは、別のコントロールに合わせて整列させるだけでなく、別のコントロールに対して適切なスペースを保つことも必要です。スペース調整は、スナップラインだけでは十分にできませんが、Control には、Padding および Margin という 2 つの新しいプロパティがあります。Padding は、フォーム、あるいはコントロールのクライアント領域の端から内側への距離をピクセル単位で指定し、その場所には、子コントロール (テキストや画像など) が侵入できないようにします。Margins は、フォームコントロールの端から外側への距離をピクセル単位で指定し、その場所には、他のコントロールが侵入できないようにします。コントロールをドラッグしたときに、コントロールとフォームの間の距離が Margins と Padding の合計である場合には、コントロールとフォームの間に青色の線が表示されます。図 7 に、コントロール間のスペースを正しく決定するために使用する、Margins、および Padding を示します。Padding、および Margin のどちらのプロパティでも、すべての方向を同時に指定すること、および方向別にそれぞれ指定することが可能です。

図 7 Margins と Padding の使用

ページのトップへ

7. 自動的なサイズ変更と拡大縮小

スナップライン、Margins、および Padding は単なるガイドにすぎず、無視される可能性があるので、コントロールは、移動、あるいはサイズ変更されることにより、完全に、あるいは部分的に非表示になってしまうことがあります。サイズ変更、あるいは移動したために隠れてしまったコントロールの部分を表示するには、コンテナコントロールをサイズ変更する必要があります。この作業は、多くのコントロールが関係する場合には手間がかかります。この代わりに、AutoSize プロパティ、および AutoSizeMode プロパティを使用できます。AutoSize は、Boolean プロパティであり、コントロールがその内容に合わせて自動的にサイズ変更されるようにする場合は True に設定します。AutoSizeMode プロパティでは、コントロールをどのようにサイズ変更するかを指示します。AutoSizeMode (System.Windows.Forms) 列挙体の GrowOnly、および GrowAndShrink の値を指定します。

GrowOnly は、中に含まれるコントロールのサイズが、コンテナのサイズ以上になった場合に、コンテナが自動的にサイズ変更されることを示します。GrowAndShrink は、コンテナが、中に含まれるコントロールのサイズ変更、および移動に合わせて、大きくも、小さくもなることを示します。図 8 を参照してください。

図 8 GrowAndShrink による自動サイズ変更

自動サイズ変更は、コントロールの端が、それをホストするコンテナの右端および下端に近づき、Margins と重なるときに発生します。AutoSize のみをサポートするコントロールと、AutoSize と一緒に AutoSizeMode もサポートするコントロールがあります。Forms のようなコントロールは、両方を実装しますが、それを使用できるのは実行時のみです。自動サイズ変更のサポートのレベルについては、コントロールごとに確認する必要があります。

フォーム、およびコントロールは、内容に合わせて自動的にサイズを変更できるだけでなく、DPI 設定に合わせて、サイズおよび位置について一貫した割合を保つように自動的にサイズを変更することもできます。DPI 設定が異なる場合でも、同一の割合、つまり縮尺を保つには、主に、2 つの要素が必要です。まず、1 つ目は、フォームに、自動的に拡大縮小するように指示します。2 つ目の要素は、フォーム、およびそれに含まれるコントロールのサイズ、および位置に適用する倍率をフォームに指示します。既定では、AutoScale プロパティが True に設定されており、フォームは自動的に拡大縮小します。倍率は、AutoScaleMode プロパティによって指定します。これは、以下のいずれかの値にできます。

enum AutoScaleMode {
    None = 0, // 拡大縮小なし
    Font = 1, // フォント サイズに合わせて拡大縮小 (既定)
    Dpi = 2, // dpi に合わせて拡大縮小
    Inherit = 3 // コンテナの AutoScaleMode を継承
}

既定は、Font です。これは、倍率がフォームが作成されたときと、フォームが実行されたときの、既定のシステムフォントの平均的な高さと幅の比率に基づくことを意味します。たとえば、フォームが Windows XP の標準フォント (96 DPI) で作成される場合、既定のフォントは 8.25pt MS Sans Serif であり、平均的な幅と高さは 6x13 です。この情報は、Windows フォームデザイナによって、次のように、フォームの AutoScaleDimensions プロパティに自動的に保管されます。

// AutoScalingForm.designer.cs 
partial class AutoScalingForm {
    ...
    void InitializeComponent() {
        ...
        this.AutoScaleDimensions = new SizeF(6F, 13F);
        ...
    }
}

この後、フォームが、大きいフォント (120 DPI) で開かれたり、実行されたりした場合、その環境の既定のフォントは 7.8pt MS Sans Serif となり、フォントの平均的な幅と高さは 8x16 と大きくなります。フォームは、AutoScaleDimensions と現在のサイズの差異を認識し、その差異を計算して、コントロールの幅、高さ、および位置を調整します。これにより、どのようなシステムフォントの設定であっても、フォームの全体的な見た目はほぼ同じに保たれます。同様の動作で、Visual Studio 内でも一貫性が保たれます。

AutoSizeMode.Font では、DPI によって変わるフォントの差に基づいて拡大縮小が行われますが、AutoSizeMode.Dpi では、単に、DPI の差に基づいて拡大縮小が行われます。図 9 に、2 つのモードの比較を示します。

図 9 96 DPI から 120 DPI への自動的な拡大

AutoScaleMode.Font と AutoScaleMode.Dpi の実際の差は、プロポーショナルフォントの縮尺が、純粋な線形の DPI の縮尺とは異なり、また、言語によっても異なるため、この 2 つが同じ比率では拡大縮小されないために発生します。AutoScaleMode.Font は、最も堅牢な選択肢であるために既定となっています。

ページのトップへ

8. TableLayoutPanel と FlowLayoutPanel

スナップライン、Margins、Padding、自動的なサイズ変更、および自動的な拡大縮小は、使いやすいレイアウトツールではありますが、これだけでは、サイズ変更可能なダイアログで多数のコントロールをホストするような複雑なシナリオを簡単にサポートすることはできません。このようなシナリオに対応するため、Windows フォームには、新たに、レイアウトコントロールとして TableLayoutPanel、および FlowLayoutPanel の 2 つが組み込まれています。

TableLayoutPanel は、HTML スタイルのテーブルレイアウトをサポートします。行と列を定義し、次の 3 つの方法のいずれかでサイズを自動的に構成できます。

AutoSize: その内容に合わせて自動的にサイズ変更します。
Percent: TableLayoutControl の全体の高さ、あるいは幅に対するパーセンテージでサイズを指定します。
Absolute: ピクセル単位での固定サイズです。

行と列は、Windows フォームデザイナから管理、およびサイズ変更できます。各セルには、1 つのコントロールを含めることができ、セル内でのそのコントロールの位置は、ドッキングとアンカーによって決まります。図 10 に、TableLayoutPanel の動作の例を示します。ここでは、[OK] ボタン、および [Cancel] ボタンの 2 つは、ネストされた TableLayoutPanel 内でホストされています。TableLayoutPanel のネストは、1 つのセルに複数のコントロールを含める必要がある場合に役立つ技法です。

図 10 TableLayoutPanel コントロール

FlowLayoutPanel は、HTML スタイルのフローレイアウトをサポートします。FlowLayoutPanel では、サイズ変更の際に、含まれるコントロールが移動する方向を設定できます。この設定は、FlowDirection プロパティに、LeftToRight、TopDown、RightToLeft、および BottomUp の値を指定して行います。

Web ページと同様、FlowLayoutPanel を、中に含まれるコントロールが移動できなくなるまでサイズ変更した場合には、FlowLayoutPanel の縦方向、または横方向の端のいずれか、あるいはその両方によって、コントロールが部分的に、または完全に見えなくなってしまうことがあります。このような場合に対応するには、AutoScroll プロパティを True に設定し、必要に応じて、縦方向、および横方向のスクロールバーが表示されるようにします。

ページのトップへ

9. コントロールとコンポーネント

Windows Forms 2.0 は、MaskedTextBox、WebBrowser、BackgroundWorker など、以前のツールボックスにはなかった機能に注目した、さまざまな新しいコントロール、およびコンポーネントが追加されて完成しています。さらに、コントロール、およびコンポーネントのライブラリ全体にわたってさまざまな点で改良が行われています。たとえば、コモンコントロールで現在の Windows テーマをその場で視覚的に反映する機能、および開発者が、構成を集中的に、よりすばやく行えるようにする、スマートタグのデザイナサポートなどがあります。

ページのトップへ

10. MaskedTextBox コントロール

MaskedTextBox コントロールは、情報性の高い正確なデータ入力作業が行えるように、マスクを使用して、入力するデータの型、および形式に関するヒントを表示し、ユーザーをガイドすることを目的としています (図 11 を参照)。マスクの文字は多数あります。マスクを作成し、テストするための支援が必要な場合には、プロパティウィンドウから、MaskedTextBox コントロールの定型入力エディタを開きます。

図 11 MaskedTextBox の定型の例

マスクの説明	データ形式	型の確認
数値 (5 桁)	12345	Int32
電話番号	(574) 555-0123	(なし)
日付	12/11/2003	DateTime
日付と時間 (US)	12/11/2003 11:20	DateTime
時間 (ヨーロッパ、および軍隊)	23:20	DateTime
郵便番号	98052-6399	(なし)

マスクでない文字、たとえば、かっこ、ハイフン、スペースなどは、既定で、文字そのものとして扱われ、必要とされるデータの形式を示すために実行時に表示されます。一方、すべてのマスク文字は、実行時に、プロンプト文字 (既定では、アンダースコアであり、図 12 に示すように、MaskedTextBox にフォーカスがある場合にのみ表示されます) に置き換えられます。

図 12 MaskedTextBox

MaskedTextBox は、さまざまなプロパティを実装しています。重要なプロパティのいくつかを 図 13 に示します。MaskedTextBox は、高度に構成可能なコントロールです。データ入力作業において、より多くの情報をユーザーに提供する必要がある場合には、使用することを検討してください。

図 13 MaskedTextBox の重要なプロパティ

プロパティ	説明
HidePromptOnLeave	既定では True です。False に設定した場合は、プロンプト文字が常に表示されるようになります。
PromptChar	プロンプト文字を変更するために使用します。既定では、アンダースコアです。
AllowPromptAsInput	場合によっては、プロンプト文字も有効な値であることがあります。どちらも適当に変更することが難しい場合は、AllowPromptAsInput を True に設定することにより、プロンプト文字も入力値とすることができます。
BeepOnError	無効な文字が入力されたときに、ビープ音を出します。
CutCopyMaskFormat	マスクされたテキストボックスのデータがどのようにコピーされるかを指定します。MaskFormat 列挙体の 4 つの値、ExcludePromptAndLiterals、IncludePrompt、IncludeLiterals、および IncludePromptAndLiterals の中の 1 つを設定します。

ページのトップへ

11. Web ブラウザ

Windows フォームアプリケーションで Web のブラウズをサポートすることは、相互運用性の COM コントロールを使用することで常に可能ではありましたが、これには、プログラミングの手間が多少かかりました。しかし、新規の Web Browser コントロールによって、図 14 に示すように、Windows フォームアプリケーションに Web ブラウズの機能を簡単に追加するマネージな手段が提供されます。

図 14 WebBrowser コントロールの動作

特定の URL への移動は、次のように、WebBrowser の Navigate メソッドを呼び出すことで簡単に行えます。

void goButton_Click(object sender, EventArgs e) {
    // URL へ移動
    this.webBrowser.Navigate(this.urlTextBox.Text);
}

WebControl が新しいページに移動したときには、ページのダウンロードが開始する前に、Navigated イベントが発生します。WebControl では、ページのダウンロードの進行状況をモニタできる ProgressChanged イベントも発生します。また、WebBrowser には、次のような、どのブラウザにもあるような標準的な移動のオプションを処理するメソッドがいくつかあります。

this.webBrowser.GoBack();    // 履歴の前のページに移動します。
this.webBrowser.GoForward(); // 履歴の次のページに移動します。
this.webBrowser.Stop();      // 現在のページのロードを停止します。
this.webBrowser.Refresh();   // 現在のページを更新します。
this.webBrowser.GoHome();    // ホームのページに移動します。

ページのトップへ

12. BackgroundWorker コンポーネント

Windows フォームアプリケーションでは、多くの場合、検索のようなバックグラウンド処理の実行が必要とされます。これに対応するには、.NET のマルチスレッド化のサポートを使用し、ワーカースレッドで長時間実行処理を非同期に実行し、その間、メインの UI スレッドは、ユーザーの要求にサービスし続けることができるようにします。しかし、ワーカースレッドのコーディングは、難しく、時間もかかります。

Windows Forms 2.0 では、BackgroundWorker を使用できます。これは、ワーカースレッドの作成、および管理の複雑さをカプセル化したコンポーネントで、Visual Studio でフォームにドラッグできます。BackgroundWorker.RunWorkerAsync を呼び出すと、ワーカースレッドから BackgroundWorker.DoWork イベントが発生します。このイベントを取得して、長時間実行処理のコードを実行します。RunWorkerAsync、および DoWork のコードを図 15 に示します。

図 15 バックグラウンドでの処理

public partial class TaskForm : Form
{
    // UI スレッドで実行
    void startOperationButton_Click(object sender, EventArgs e)
    {
        // ワーカー スレッドに渡すデータを作成します。
        MyData data = new MyData();
        ...
        // ワーカー スレッドを開始します。
        this.backgroundWorker.RunWorkerAsync(data);
    }

    // ワーカー スレッドで実行
    void backgroundWorker_DoWork(object sender, DoWorkEventArgs e) 
    {
        // UI スレッドから渡されたデータを抽出します。
        MyData data = (MyData)e.Argument;

        // 長時間かかる、非同期な処理を実行します。
        ...
    }
}

BackgroundWorker は、UI とワーカースレッドの間のデータの受け渡しが、スレッドセーフな方法で行われるようにします。BackgroundWorker は、進行状況のレポート、および取り消しもサポートします。また、これはコンポーネントであるので、このような機能性をデザイナから構成できます。

ページのトップへ

13. オートコンプリート

いくつかのコントロールに適用された改良の 1 つとして、オートコンプリートがあります。これは、ComboBox、TextBox、ToolStripComboBox、および ToolStripTextBox で実装されます。これには、3 つのプロパティ、AutoCompleteMode、AutoCompleteSource、および AutoCompleteCustomSource があります。AutoCompleteMode では、オートコンプリートのスタイルを、同じ名前の列挙体から設定できます。

enum AutoCompleteMode {
    None = 0,         // オート コンプリートなし (既定)
    Suggest = 1,      // ドロップダウン リストから可能な一致を選択
    Append = 2,       // 入力中のテキストに可能な一致を追加
    SuggestAppend = 3 // AutoSuggest と AutoAppend の両方
}

"None" 以外のオプションでは、AutoCompleteSource プロパティを、次のように、AutoCompleteSource 列挙体で指定されるシステムオートコンプリートソースの 1 つに設定する必要があります。

enum AutoCompleteSource {
    FileSystem = 1,       // ファイル システム
    HistoryList = 2,      // 履歴リストからのすべての URL
    RecentlyUsedList = 4  // 最近使用したリストからのすべての URL 
    AllUrl = 6,           // HistoryList と RecentlyUsedList の両方
    AllSystemSources = 7, // FileSystem と AllURL の両方
    FileSystemDirectories = 0x20, // ファイル システムのフォルダ
    CustomSource = 0x40,  // AutoCompleteCustomSource
    None = 0x80,          // ソースなし (既定)
    ListItems = 0x100     // コントロールのリスト内の項目 (コンボ ボックスの場合のみ)
}

CustomSource の選択は、AutoCompleteCustomSource プロパティに格納されている項目のコレクションからオートコンプリートオプションを提供することを ComboBox に指示します。ListItems は、ComboBox の List プロパティに格納されている項目をソースに指定します。

ページのトップへ

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

究極のクールさで特筆すべきコントロールは、ストリップコントロールでしょう。図 16 に示すように、MenuStrip、ToolStrip、StatusStrip、および ContextMenuStrip を追加すれば、ユーザーインターフェイスが最新の雰囲気になります。

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

MainMenu、ToolBar、StatusBar、および ContextMenu (下位互換の目的で Windows Forms 2.0 にも残ります) の後継である新規のストリップコントロールでは、次のような点が改善されています。

すべてのストリップコントロールに共通する API
デザイン時エクスペリエンスの改善
フォームの一辺から別の辺へのドラッグ
Office 2003 および Windows テーマの反映
ドロップダウンリスト、ラベル、メニュー、およびテキストボックスなど、多様な子コントロールのホスト
カスタム描画サポートの簡略化
設定システムとの統合
フォームの MainMenuStrip プロパティとの統合、およびコントロールの ContextMenuStrip プロパティとの統合

ストリップコントロールは、さまざまなデザイン時サポートを提供します。中でも重要なのは、各ストリップコントロールへの項目の追加が簡略化されていることです。ストリップコントロールに追加できる項目は、ストリップコントロールの用途によって異なります。図 17 に、概要を示します。

図 17 ストリップコントロールの項目とそのホスト

ストリップコントロール	デザイナが許可するストリップ項目コントロール
MenuStrip	ToolStripMenuItem (トップメニュー、およびサブメニューの両方の項目) ToolStripComboBox ToolStripTextBox ToolStripSeparator (サブメニュー)
ContextMenuStrip	MenuStrip と同じ
ToolStrip	ToolStripButton ToolStripComboBox ToolStripSplitButton ToolStripLabel ToolStripSeparator ToolStripDropDownButton ToolStripTextBox ToolStripProgressBar
StatusStrip	ToolStripStatusLabel ToolStripProgressBar ToolStripDropDownButton ToolStripSplitButton

ストリップコントロールの項目の追加、更新、および削除は、プロパティウィンドウ、あるいはスマートタグから行えます。また、デザイン画面から視覚的に行うこともできます。MenuStrip、および ToolStrip の 2 つには、[開く]、[上書き保存]、[名前をつけて保存]、[切り取り]、[コピー]、および [貼り付け] など、よく使用されるコマンドの項目をコントロールに事前に組み込むための [標準項目の挿入] オプションが提供されています。

ストリップコントロールのプロパティウィンドウ、およびスマートタグのサポートでは、他にも、さまざまな重要な構成が使用可能です。プロパティによって制御される重要な構成のいくつかを、図 18 に示します。図 19 には、Enabled、Visible、Checked および BorderStyle など通常のコントロールに存在する標準的なプロパティの他に、ストリップコントロールが追加で提供するプロパティの概要を示します。

図 18 ストリップコントロールのプロパティによる主な構成

プロパティ	説明
AllowItemReorder	このプロパティを True に設定した場合は、Office 2003 のツールバーと同様に、ユーザーがストリップ項目の位置を変更できるようになります。ただし、ユーザーは、これも Office 2003 と同様で、位置を変更する前に Alt キーを押す必要があります。(ContextMenuStrip は除きます。)
CanOverflow	このオプションは、フォームの幅や高さが、ストリップコントロールの表示に十分でなくなった場合に、重なって隠れてしまったツールストリップの項目を視覚的にどのように表示するかを指定します。False の場合には隠れます。True の場合は、ストリップコントロールの端に表示されるドロップダウンによってアクセス可能になります。
Dock	フォームの一辺全体に並べるかどうかを指定します。
GripStyle	MenuStrip、あるいは ToolStrip が、その位置の変更を可能にするハンドルを表示するかどうかを指定します。
Renderer	既定以外のツールストリップ UI を提供するカスタム ToolStripRenderer 実装を設定します。この場合、RenderMode が Custom に設定されます。
RenderMode	ストリップコントロールは、次の 4 つの描画モードをサポートします。 System: システムパレットからの色で描画します。Professional: 現在の Windows の配色 (青、オリーブグリーン、あるいはシルバーのいずれか) に従って描画します。ManagerRenderMode: Windows テーマを反映する ToolStripRenderer を使用して描画します。これが、既定です。 Custom: 明示的に設定することはできません。Renderer プロパティを参照してください。
ShowItemToolTips	ストリップ項目もツールヒントを表示できるようにするかどうかを設定します。(MenuStrip、および ContextMenuStrip では False です。)
SizingGrip	フォームのサイズ変更ハンドルを表示するか、しないかを設定します。(StatusStrip のみ。)

図 19 ツールストリップ項目コントロールの主なプロパティ

プロパティ	説明
Alignment	ツールストリップコントロールのどちらの端に合わせて、ツールストリップ項目コントロールを整列させるかを、Left、あるいは Right で決定します。
DisplayStyle	None、Text、Image、ImageAndText など、表示する要素を指定します。
ImageScaling	画像をどのように描画するかを、ShrinkToFit、あるいは None で指定します。
Overflow	オーバーフローに対して、各ストリップ項目コントロールがどのように対応するかを決定します。Never、Always、あるいはホストストリップコントロールの判断に任せる AsNeeded を指定できます。
TextImageRelation	画像に対するテキストの位置を設定します。DisplayStyle が ImageAndText の場合に適用されます。

ページのトップへ

15. ストリップコンテナ

一連のストリップコントロールの重要な機能の 1 つとして、フォームのある一辺から別の辺にドラッグできる機能があります。ストリップコントロールは、既定でフォームの辺にドッキングされますが、ドッキングされると、このようなドラッグがサポートされません。これに対応するため、図 20 に示すように、ToolStripContainer コントロールによってドラッグの動作をフォームに追加します。

図 20 ToolStripContainer コントロール

ToolStripContainer は、フォーム全体のストリップコントロールの動作を提供するコンテナコントロールであるので、他のコントロールを追加する前にフォームに追加する必要があります。コンテナを追加した後、コントロールは、コンテンツ用パネルに追加し、ストリップコントロールは、4 つの特殊なパネルの 1 つに追加します。各パネルは、展開、あるいは縮小することができ、フォームのそれぞれの辺のストリップコントロールを保持します。パネルの表示、あるいは非表示は、必要に応じて、ToolStripContainer の TopToolStripPanelVisible、RightToolStripPanelVisible、BottomToolStripPanelVisible および LeftToolStripPanelVisible の Boolean プロパティを設定することにより切り替えられます。

実行時、ストリップコントロールは、フォームの、パネルが表示となっている辺から辺にドラッグすることができます。ドラッグできるのは、移動ハンドルを持つストリップコントロールのみです。同じツールストリップパネル内に、複数のツールストリップコントロールが存在する場合、ユーザーは、必要に応じてそれぞれの位置を変更できます。ユーザーは、ツールストリップを実行時に別の位置に移動できるので、アプリケーションの現在のセッションでの位置が、次回も保持されていることを期待します。これには、ToolStripManager クラス (System.Windows.Forms から) を使用します。このクラスには、便利な static (shared) LoadSettings メソッド、および SaveSettings メソッドが実装されています。

ページのトップへ

16. データバインディング

Windows Forms 2.0 では、新たな BindingSource コンポーネントにより、データバインディングがより強力になりました。このコンポーネントの主な役割は、データバインディング向きでないデータソースを、より強力なデータバインディング機能でアップグレードすることです。これは、別個の複数のデータソースの一体化を可能にし、さらに、どのような種類のデータソースに対しても、クライアントコードのパターンは 1 つにすることを実現します。

データソースは、データソース構成ウィザード ([データ] の [新しいデータソースの追加]) を使用して簡単にプロジェクトに追加できます。このウィザードで、データベース、Web サービス、およびオブジェクトを取得元とするデータソースを作成できます。データベースからデータソースを作成する場合は、厳密に型指定された DataSet がプロジェクトに新しく追加されます。これは、図 21 に示すように、新しいデータソースウィンドウ ([ツール]、[データ] の [データソースの表示]) から表示できます。

図 21 データソース
図 21 データソース

データソースウィンドウには、ツールストリップの項目があり、そこから新しいデータソースを追加できます。また、データソースが厳密に型指定された DataSet である場合には、編集、再構成、あるいは更新を行うこともできます。DataGridView などのコントロールをフォームにドロップした場合には、自動的に、データソースを選択、あるいは新規作成するためのプロンプトが表示されます。

ページのトップへ

17. BindingSource

"データソース" を考える場合、最も一般的なのは型指定された DataSet です。しかし、データソースは、テーブル、XML、および .NET ベースのオブジェクトなど、多様な形式、および大きさにすることができます。これらはすべて、Windows Forms 1.x でも連結できましたが、データバインディングの統合のレベルが今回とは違いました。開発者は、IBindingList を実装して高レベルなデータバインディング統合を実現するために、多くの時間をかけてデータソースの更新をしていました。Windows Forms 2.0 BindingSource コンポーネントにより、この問題が解決されます。どのような型のリストも使用でき、そのリストを、IBindingList リストデータソース実装として再提供することができるようになりました。さらに、項目の型も BindingSource コンポーネントに渡されるようになり、これも、IBindingList 実装に反映されます。

BindingSource で目的のデータソースを使用するように構成するには、このコンポーネントをフォームにドロップし、DataSource プロパティ、および DataMember プロパティを適切に設定します。以下に、型指定された DataSet を使用する BindingSource の例を示します。

public partial class DataBindingForm : Form {
    public DataBindingForm() {
        ...
        // 型指定されたデータ セットを使用します。
        this.bindingSource.DataSource = this.northwindDataSet;
        this.bindingSource.DataMember = "Employees";
    }
}

これで、BindingSource コンポーネントが、厳密に型指定された DataSet を、コントロールの連結先のデータソースとして提供します。

ページのトップへ

18. DataGridView

Windows フォームのチームでは、コミュニティからの DataGrid に関するフィードバックに応えて、まったく新しいグリッドコントロールとして System.Windows.Forms.DataGridView を作成しました (DataGrid は、階層データの移動、および編集用として存在しています)。

DataGrid と DataGridView の大きな違いの 1 つは、オブジェクトモデルです。DataGridView のオブジェクトモデルは、図 22 に示すような、列、行、およびセルで構成される自然なグリッド構造として抽象化されます。この自然なグリッド構造により、開発者は、次のような、直感的に見つけられる多くの機能性に、すばやく、論理的に到達することができます。

スタイル、書式設定、レイアウト、および項目の選択によるリッチな UI カスタマイズ。
DataGrid とは異なり、画像などの多様なデータ型をネイティブに表示する機能。
固定列、および実行時の列の順序変更などの便利な機能。
移動、編集、検証、カスタム描画、およびエラー処理を詳細に制御するための 100 以上のイベント。

図 22 DataGridView オブジェクトモデル
図 22 DataGridView オブジェクトモデル

新しい機能の 1 つとして、セルのクリックによる行の選択があります。これは、DataGridView の SelectionMode プロパティで構成します。当然ながら、どのような状況にも完璧であるコントロールは存在しません。必要な場合には、開発者が、拡張性を活用してカスタム機能を組み込むことができます。DataGridView インフラストラクチャには、DataGridViewColumn、DataGridViewCell など、派生させて組み込むことができる、セル、行、および列のさまざまな基本実装があります。このように、グリッドスタイルのコントロールとして、DataGridView は、DataGrid から大幅に強化されています。

DataGridView にデータを設定する方法として最も一般的なのは、図 23 に示すように、DataSource プロパティに BindingSource を設定して行う方法です。

図 23 DataGridView での BindingSource の連結

DataGridView では複数の項目を表示しますが、同時に 1 つの項目のみを表示することもあります。このような場合は、単純に、TextBox のようなコントロールを BindingSource に連結します。ただし、同時に 1 つの項目のみを表示する場合は、ユーザーが項目を移動する手段を提供する必要があります。このようなサポートは、通常、VCR スタイルのコントロールで提供します。独自に作成しなくても、BindingNavigator をフォームにドラッグし、それを、コントロールが連結されているのと同じ BindingSource に連結します。BindingNavigator は、現在の項目、および総項目数の情報も提供します。また、データソースに対する項目の追加、および削除もサポートします。

ページのトップへ

19. ドラッグアンドドロップによるデータバインディング

コントロール、およびコンポーネントをドラッグアンドドロップして、それをフックするコードを記述するという作業は、データバインディングで生産性を向上させるという概念に合致していないようにも思えます。UI を手動でドラッグアンドドロップし、それを構成する代わりに、データソースウィンドウからデータソースをフォームにドラッグアンドドロップすれば、Windows フォームデザイナが自動的に、連結された UI を作成し、構成します。

データソースをドラッグアンドドロップした場合は、Windows フォームデザイナが次の処理を行います。

そのデータソースの BindingSource を追加します。
必要に応じて、厳密に型指定された DataSet、およびテーブルアダプタを追加します。
BindingSource に連結する必要なコントロールを追加し、それらに適切な名前を付けます (DataGridView の列以外)
BindingSource に連結する BindingNavigator を追加します。

また、データソースをドロップしたときに、DataGridView、あるいは詳細のどちらの UI が作成されるか、またどちらの場合でも、それに合わせてどのコントロールが生成されるかは、構成することができます。

ページのトップへ

20. ClickOnce 配置

アプリケーションは、最終的には配置する必要があります。setup アプリケーション、あるいは Microsoft インストーラ (MSI) ファイルは、配置の優れた技法ですが、これらは、配布され、クライアント上で実行される必要があります。また、インストール済みの環境を最新に保つ必要もあります。これは、困難な場合があります。Web アプリケーションには、ユーザーが何もしなくても、バージョンが最新に保たれる、優れた配置モデルがあります。

優れた技法は、他の技法を借用します。そして、最も優れた技法は、他の技法を完全に取り込みます。Windows Forms 1.x には、"ノータッチデプロイメント" (NTD) として知られる技法があります。これは、Web 開発モデルからの借用であり、Windows フォームアプリケーションが、URL、あるいは UNC ファイルパスのいずれかから配置され、コードアクセスセキュリティ (CAS) で制御されるクライアントマシン上のサンドボックス内で実行されるようにします。Windows Forms 2.0 では、NTD が、Web スタイルの配置モデルを Windows フォームアプリケーションに導入し、ClickOnce 配置に進化しました。ClickOnce には、次のような機能があります。

作成、発行、および配置されたアプリケーションの管理に関する豊富な構成。

Web サーバー、FTP サーバー、ファイル共有、および CD や DVD といったメディアなど、複数の発行場所。
ハイパーリンクスタイルでのアプリケーションの起動。
オンラインのみと、オンラインおよびオフラインの 2 つのインストールモード。オンラインおよびオフラインの場合、ClickOnce アプリケーションは、ユーザーのマシンでネットワーク接続がキャッシュされていない場合でも起動できます。
[スタート] メニュー、コントロールパネルの [プログラムの追加と削除] など、クライアントとの統合のレベルに対する制御。
.NET Framework 2.0 など、インストールに必須な条件の選択 ([必須コンポーネント] ボタンから)
ファイル、およびアセンブリの依存関係の管理
発行者の詳細、サポート Web ページ、および ClickOnce が自動的に生成する配置 Web ページなど、発行に関する各種の詳細な設定。
発行バージョン番号の使用。さまざまなシナリオにおけるバージョン管理ポリシーの作成が可能です。
コード署名、および完全にユーザードリブンである CAS に基づいて構築されている、信頼された配置および実行モデル。
Visual Studio との完全な統合。

ClickOnce 配置は、デザイン時に、Visual Studio で、図 24 に示すように、プロジェクトプロパティページの [発行] タブから構成できます。アプリケーションの発行の際には、これらの各種の構成が結合され、適用されます。

図 24 ClickOnce 配置の構成

ページのトップへ

21. 発行

アプリケーションを最も簡単に発行するには、ソリューションエクスプローラでプロジェクトを右クリックして、[発行] を選択します。これにより、発行ウィザードが開くので、ここで、発行場所やインストールモードなど各種の詳細を設定します。

アプリケーションが発行される場合は、Visual Studio および ClickOnce が、指定された構成に基づいてインストールパッケージを準備し、それを発行場所にコピーします。ClickOnce は、アプリケーション名と発行するバージョン番号を組み合わせた名前でフォルダを生成します。このフォルダには、メインアプリケーションアセンブリ、および他の必要なファイルが含まれます。Web サーバーに発行する場合、それぞれのファイルには、".deploy" が後ろに付加されます。Web サーバーのポリシーによっては、一般的な実行可能ファイルタイプ (.exe、.dll) は、アップロードが許可されない場合があります。インストールパッケージを構成するファイルを保管するために、ClickOnce は、アプリケーションマニフェスト (.manifest) を生成します。このファイルには、Visual Studio から行った各種の構成も含まれます。

アプリケーションは、複数のバージョンが発行されることもあるので、ユーザーには、どのバージョンをダウンロードするかを決定する手段が必要です。このために、ClickOnce は、配置マニフェスト (.application) を生成し、図 25 に示すように、それを発行されたアプリケーションのルートに追加します。

図 25 ClickOnce で発行されたアプリケーション

配置マニフェストは、2 つ生成されています。1 つは、最新の発行バージョン用であり、もう 1 つは特定のバージョン用です。ルートには、.NET Framework 2.0 などの必須コンポーネントがない場合に、ユーザーが実行する setup アプリケーションが作成されます。また、ユーザーが参照し、発行されているアプリケーションを起動するための既定の Web ページも作成されます。アプリケーションを起動するには、ユーザーが [インストール] ボタンをクリックします。このボタンは、最新バージョンのアプリケーションマニフェストを指すハイパーリンクです。

ページのトップへ

22. セキュリティ

アプリケーションが起動されたとき、ClickOnce は、ダウンロードし、実行するアプリケーションが安全であるかどうかを判断するために、ユーザーの介入なしで、まず、マニフェストをダウンロードします。セキュリティの問題が検出された場合には、[セキュリティ警告] ダイアログが表示されます。セキュリティの問題がある場合は、アプリケーションのインストールを続行するかどうかを、ユーザーが選択します。ユーザーは、判断を行うために、[詳細] リンクをクリックしてセキュリティの問題の詳細を参照できます。

ClickOnce では、発行者、マシンアクセス、インストール、場所の 4 つのカテゴリに警告が分類されます。発行者は、アプリケーションを発行した人についての説明です。発行者が ClickOnce によって安全とみなされるためには、Verisign などの認証局から発行された電子証明書を使用して、コードに署名をする必要があります。アプリケーションの署名は、Visual Studio で、プロジェクトのプロパティページの [署名] タブから行えます。このタブでは、証明書を、証明書のストア、あるいはファイルからインポートしたり、テスト証明書を作成したりできます。また、証明書の有効期限のためのタイムスタンプサーバーを指定したり、アセンブリの署名や遅延署名を行ったりすることもできます。

マシンアクセスは、アプリケーションをクライアントマシン上で実行するために必要な許可について説明します。ClickOnce アプリケーションの許可は、.NET CAS によって管理されます。これは、.NET 対応アプリケーションを、アプリケーションに付与された許可のみを可能にするセキュリティサンドボックス内で実行することをラップします。ClickOnce は、起動しようとしているアプリケーションに必要な許可が、同じゾーンから起動されるアプリケーションに許されている許可を超えている場合に、セキュリティの警告を発生させます。ユーザーが、許されている許可以上の許可要件でアプリケーションをインストールすることを選択した場合には、CAS がこれらの許可をアプリケーションに付与します。このプロセスは、許可の昇格と言われます。アプリケーションの許可要件は、図 26 に示すように、プロジェクトのプロパティページの [セキュリティ] タブから管理できます。

図 26 ClickOnce のセキュリティ設定

[セキュリティ] タブでは、完全信頼か、部分信頼かを指定できます。部分信頼とする場合には、必要な許可を手動で選択するか、あるいは自動で計算させます。対象とするゾーンの既定の許可を選択し、必要に応じてそれを変更することもできます。アプリケーションのデバッグは、特定のゾーンから配置され、特定の許可に制限されているものとして行うことができます。

ページのトップへ

23. まとめ

Windows Forms 2.0 の新機能について、広範囲にわたり、詳しく説明しました。新機能は、MSDNマガジンで 1 年をかけても説明しきれないほどであるので、関心が集まるのも当然のことです。ここでは、より拡張され、強力になった .NET Framework、新しいコントロールやコンポーネント、データバインディングの進化、ClickOnce 配置、および Visual Studio とのより緊密な統合について説明したので、さらなる調査を開始する準備はできたことと思われます。Windows Forms 2.0 を理解できれば、今後、長期にわたり Windows アプリケーション開発プラットフォームのトップ製品であり続けるであろうテクノロジを使用して、より機能豊富な Windows フォームアプリケーションを、これまでよりも短時間で構築できるようになります。

ページのトップへ

Chris Sells は、マイクロソフトの Connected Systems Division のプログラムマネージャであり、次世代アプリケーション開発技術に携わっています。Chris や、彼のさまざまプロジェクトの詳細については、www.sellsbrothers.com を参照してください。

Michael Weinhardt は、現在、『Windows Forms Programming in C#』(Chris Sells との共著 Addison-Wesley Professional 刊、2003 年) の改訂に取り組んでいます。また、MSDN Online のコラム「Wonders of Windows Forms」も、毎月、執筆しています。詳細については、www.mikedub.net を参照してください。

この記事は、MSDN マガジン - Visual Studio 2005 ガイドツアー号からの翻訳です。

QJ: 560005

ページのトップへ

次の方法で共有

スマートクライアント

強化された Windows フォームサポートによる .NET アプリケーションのリッチな UI の作成

目次

1. Windows フォームプロジェクト

2. コード分離

3. リソース管理の改善

4. 設定管理の改善

5. System.Windows.Forms.Form

6. スナップライン、Margins、および Padding

7. 自動的なサイズ変更と拡大縮小

8. TableLayoutPanel と FlowLayoutPanel

9. コントロールとコンポーネント

10. MaskedTextBox コントロール

11. Web ブラウザ

12. BackgroundWorker コンポーネント

13. オートコンプリート

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

15. ストリップコンテナ

16. データバインディング

17. BindingSource

18. DataGridView

19. ドラッグアンドドロップによるデータバインディング

20. ClickOnce 配置

21. 発行

22. セキュリティ

23. まとめ

その他のリソース

次の方法で共有

スマート クライアント

強化された Windows フォーム サポートによる .NET アプリケーションのリッチな UI の作成

目次

1. Windows フォーム プロジェクト

2. コード分離

3. リソース管理の改善

4. 設定管理の改善

5. System.Windows.Forms.Form

6. スナップ ライン、Margins、および Padding

7. 自動的なサイズ変更と拡大縮小

8. TableLayoutPanel と FlowLayoutPanel

9. コントロールとコンポーネント

10. MaskedTextBox コントロール

11. Web ブラウザ

12. BackgroundWorker コンポーネント

13. オート コンプリート

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

15. ストリップ コンテナ

16. データ バインディング

17. BindingSource

18. DataGridView

19. ドラッグ アンド ドロップによるデータ バインディング

20. ClickOnce 配置

21. 発行

22. セキュリティ

23. まとめ

その他のリソース

スマートクライアント

強化された Windows フォームサポートによる .NET アプリケーションのリッチな UI の作成

1. Windows フォームプロジェクト

6. スナップライン、Margins、および Padding

13. オートコンプリート

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

15. ストリップコンテナ

16. データバインディング

19. ドラッグアンドドロップによるデータバインディング