次の方法で共有

Windows Presentation Foundation の紹介

  • [アーティクル]

David Chappell

Chappell & Associates

2006 年 9 月

適用対象:

   Windows Vista

   Windows Presentation Foundation

   Microsoft .NET Framework 3.0

概要 : Windows Presentation Foundation (WPF) の第一の目標は、魅力的で効果的なユーザー インターフェイスを作成できるよう開発者を支援することです。WPF の統合プラットフォームは、デザイナがユーザー インターフェイスの作成過程に積極的に参加することを可能にし、またスタンドアロン アプリケーションおよびブラウザ アプリケーションに共通のプログラミング モデルを提供します。この文書では、WPF 統合プラットフォームのこれらの利点について説明します (印刷すると 34 ページ)。

目次

Windows Presentation Foundation の説明 Windows Presentation Foundation の説明
   問題点の解明 問題点の解明
   問題の解決に向けて: Windows Presentation Foundation が提供する機能 問題の解決に向けて: Windows Presentation Foundation が提供する機能
Windows Presentation Foundation の使用 Windows Presentation Foundation の使用
   Windows Presentation Foundation のテクノロジ Windows Presentation Foundation のテクノロジ
   Windows Presentation Foundation の適用 Windows Presentation Foundation の適用
Windows Presentation Foundation のツール Windows Presentation Foundation のツール
   開発者向け: Visual Studio 開発者向け: Visual Studio
   デザイナ向け: Expression Interactive Designer デザイナ向け: Expression Interactive Designer
Windows Presentation Foundation と他のマイクロソフト テクノロジ Windows Presentation Foundation と他のマイクロソフト テクノロジ
   Windows Presentation Foundation と Windows フォーム Windows Presentation Foundation と Windows フォーム
   Windows Presentation Foundation と Win32/MFC Windows Presentation Foundation と Win32/MFC
   Windows Presentation Foundation と Direct3D Windows Presentation Foundation と Direct3D
   Windows Presentation Foundation と AJAX/"Atlas" Windows Presentation Foundation と AJAX/"Atlas"
   Windows Presentation Foundation と "WPF/E" Windows Presentation Foundation と "WPF/E"
まとめ まとめ
著者紹介 著者紹介

Windows Presentation Foundation の説明

技術者が最も大きな関心を抱くのは、当然のこととしてテクノロジです。往々にして、ソフトウェアの専門家の興味は、アプリケーションがユーザーとどのようなやり取りを行うかよりも、アプリケーションの動作の仕組みに注がれます。しかし、最終的にお金を払ってアプリケーションを購入するのはユーザーであり、ユーザーが強い関心を寄せるのはユーザー インターフェイスです。アプリケーションのインターフェイスは、ソフトウェアのユーザー エクスペリエンスの大きな部分を占め、ユーザーにとってはユーザー エクスペリエンスこそがアプリケーションなのです。より優れたインターフェイスによってより良質のユーザー エクスペリエンスを提供すれば、生産性を高め、顧客ロイヤリティを獲得し、Web サイトでの売り上げを伸ばすことが可能となります。

かつては文字ばかりのインターフェイスで満足していたユーザーも、今ではグラフィカル インターフェイスに慣れ親しんでいます。しかし、ユーザー インターフェイスに対する要求はますます高度になっています。グラフィックスやメディアは今や幅広く使用されるようになっています。また、Web の普及により、現在のユーザーはソフトウェアとの対話が簡単に行えることを当然のことと考えるようになっています。ユーザーがアプリケーションとの対話に費やす時間が長くなればなるほど、アプリケーションのインターフェイスが持つ重要性も高まります。増大するこのような期待に応えるには、ユーザー インターフェイスの作成に使用されるテクノロジも進歩していかなければなりません。

Windows Presentation Foundation (WPF) の目的は、Windows にこの進歩したテクノロジを提供することです。Microsoft .NET Framework のバージョン 3.0 に含まれる WPF では、ドキュメント、メディア、2D および 3D のグラフィックス、アニメーション、また Web に似た機能などを組み込んだインターフェイスが構築できます。.NET Framework 3.0 の他のコンポーネントと同様、WPF は Windows Vista、Windows XP、および Windows Server 2003 で使用できます。WPF は、Windows Vista の出荷に合わせてリリースされる予定になっています。この文書では、WPF の紹介として、WPF のさまざまな機能について説明します。この文書の目的は、このテクノロジがどのような問題の解決に役立つのかを具体的に示し、WPF が提供するソリューションについて概観することです。

問題点の解明

一例として、患者の診察やモニタリングに使用するアプリケーションの作成を検討している病院について考えてみましょう。この新しいアプリケーションのユーザー インターフェイスが満たすべき要件には、次のようなものがあります。

  • 患者に関する画像やテキストを表示する。

  • 心拍数や血圧など、患者の健康状態を示す 2D のグラフィックスを表示および更新する。

  • 3D のビューや患者データのオーバーレイを表示する。

  • 超音波の映像などの診断データを表示する (医師や看護婦が注釈を追加できるようにする場合もある)。

  • 病院のスタッフはドキュメントに目を通し、患者や患者の容体について書き込みを行うことができる。

  • Windows アプリケーションおよび Web ブラウザ アプリケーションとして実行できる。Windows アプリケーションの場合、病院のスタッフはアプリケーションのすべての機能を使用できる。Web ブラウザ アプリケーションの場合はセキュリティが制限されるが、離れた場所にいる医師たちにもインターネットを介して制限付きのアクセスを許可できる。

これらの要件は非常に高度なものですが、非現実的ではありません。適切な情報を適切な方法および適切なタイミングで提供するユーザー インターフェイスには、大きなビジネス価値があります。また、この例のように医療の分野では、命を救うことにもなります。オンライン マーケットや他のコンシューマ指向アプリケーションなど、命にかかわらない場合でも、質の高いユーザー エクスペリエンスには、企業の提供する商品を競合他社と差別化し、売り上げと企業のブランド価値を向上する力があります。重要なのは、グラフィックス、メディア、ドキュメント、および最新のユーザー エクスペリエンスに含まれる他の要素を組み込んだインターフェイスは、今日の多くのアプリケーションにメリットをもたらすという点です。

現在のテクノロジを使用して Windows でこのようなインターフェイスを構築することは可能ですが、容易ではありません。たとえば、次のようなハードルが立ちはだかります。

  • グラフィックス、画像、ビデオの処理に多種多様なテクノロジが使用されている。これらの多様なテクノロジを適切に扱うことのできる開発者を探し出し、それらの開発者によって作成されたアプリケーションを維持管理することは至難の業であり、コストもかかる。

  • すべての機能を効果的にユーザーに提供できるインターフェイスのデザインは困難である。ソフトウェア開発者にはそのスキルがないため、専門的なデザイナが必要となる。しかし、特にこの例のように多様な機能が組み込まれたインターフェイスの場合、デザイナと開発者の共同作業は簡単ではない。

  • スタンドアロンの Windows デスクトップ アプリケーションおよびブラウザでホストされるアプリケーションの両方で多様な機能を備えたインターフェイスを提供するには、それぞれ異なるテクノロジのセットを使用して、2 つの異なる実装を構築しなければならない。Windows デスクトップ アプリケーションでは通常 Windows フォームやその他のネイティブ Windows テクノロジが使用されるのに対し、ブラウザでホストされるアプリケーションでは HTML と JavaScript が使用される。そのため、異なるスキルを備えた 2 つのグループの開発者が必要となる。

最新の効果的なユーザー インターフェイスの作成がこれほど複雑でなければならない必然的な理由はありません。統一されたアプローチを開発者に提供しつつ、デザイナが積極的な役割を発揮できる共通の基盤があれば、これらの課題すべてを解決することができます。次の節で説明するように、これこそが WPF の目指すところなのです。

問題の解決に向けて: Windows Presentation Foundation が提供する機能

WPF の提供する機能には、特に重要な 3 つの特徴があります。その 3 つとは、最新のユーザー インターフェイス向けの統合プラットフォーム、開発者とデザイナのコラボレーション、Windows および Web ブラウザ ユーザー インターフェイスに共通のテクノロジです。ここでは、これらの 3 つの特徴について順に説明します。

最新のユーザー インターフェイス向けの統合プラットフォーム

WPF の登場以前は、前述のように、複数の異なるテクノロジを使用して Windows のユーザー インターフェイスを作成していました。この状況を簡潔にまとめると、次の表のようになります。

Windows フォーム PDF Windows フォーム /
GDI+		 Windows Media Player Direct3D WPF

グラフィカル インターフェイス (フォームやコントロールなど)

X

 

 

 

 

X

画面上のドキュメント

X

 

 

 

 

X

固定書式ドキュメント

 

X

 

 

 

X

画像

 

 

X

 

 

X

ビデオとオーディオ

 

 

 

X

 

X

2D のグラフィックス

 

 

X

 

 

X

3D のグラフィックス

 

 

 

 

X

X

フォーム、コントロール、および Windows グラフィカル ユーザー インターフェイス特有の他の要素を作成するには、通常 .NET Framework に含まれる Windows フォームが使用されます。インターフェイスにドキュメントを表示する場合、画面上ドキュメントは Windows フォームでサポートされますが、固定書式ドキュメントは Adobe の PDF で表示することができます。画像や 2D グラフィックスには、GDI+ (特殊なプログラミング モデル。Windows フォームを介してアクセス可能) が使用されます。ビデオやオーディオを提供するには Windows Media Player に依存しなければならず、3D グラフィックスを表示するには Windows に標準で装備される Direct3D を使用しなければなりません。

このように複雑な状況が見られるのは、ひとえに歴史的な要因によります。この状況が非合理的であることは言うまでもありません。合理的な解決策は、1 つに統合されたソリューション、WPF を使用することです。WPF がインストールされたコンピュータ向けにアプリケーションを作成する開発者は、WPF を使用して上記の表に含まれるすべてのタイプのデータを操作できます。つまり、ユーザー インターフェイスを作成するには、独立したテクノロジの雑多な集合体ではなく、1 つの一貫した基盤を使用する方が合理的です。

WPF は、表に記載されているテクノロジすべてに取って代わるわけではありません。Windows フォーム アプリケーションは WPF 環境でも有用であり、一部の新しいアプリケーションでは引き続き Windows フォームが使用されます (WPF は Windows フォームと相互運用可能です。この点については、詳しく後述します)。Windows Media Player は今後も独立した役割を果たし、PDF ドキュメントも引き続き使用されます。Direct3D は、ゲームなどのアプリケーションにおいて、重要なテクノロジとしての立場を維持します (WPF 自体もレンダリングに関しては全面的に Direct3D に依存しています)。

とはいえ、多様な機能を単一のテクノロジで提供する WPF により、最新のユーザー インターフェイスの作成は非常に容易になります。この統合アプローチによってどのようなことが可能になるのか、上記で取り上げた WPF ベース医療アプリケーションの画面を使用して説明します。

introducingwpf1.gif

図 1: WPF インターフェイスには画像、テキスト、 2D と 3D のグラフィックスなどを組み込むことができる  

この画面には、テキストと画像に加えて、2D と 3D のグラフィックスが含まれています。これらはすべて WPF を使用して作成されました。開発者は、GDI+ や Direct3D など、特殊なグラフィックス テクノロジを使用するコードを記述する必要はありません。さらに、WPF では次の図のように超音波映像などのビデオを表示し、場合によっては注釈を付け加えることも可能です。

introducingwpf2.gif

図 2: WPF インターフェイスにはビデオを表示し、テキスト注釈を追加することも可能  

WPF では、ドキュメントを読みやすい形式で表示できます。たとえば、病院のアプリケーションでは、医師が患者の治療に関する記録を調べたり、関連する医学研究のトピックにアクセスしたりすることができます。あるいは、次の画面のように注釈を追加することもできます。

introducingwpf3.gif

図 3: WPF インターフェイスには、注釈も含めて、段組みされたドキュメントを表示できる  

ドキュメントは読みやすいように段組みで表示され、スクロールするのではなく、ページを移動できることに注目してください。読みやすい画面の追求は価値ある取り組みであり、WPF の重要な目標の 1 つでもあります。しかし、画面上ドキュメントが便利であるとはいえ、固定書式ドキュメントを使用する方が適切な場合もあります。固定書式ドキュメントは画面上でもプリンタ上でも外観が変化しないため、どのような状態でも標準的な外観を維持できます。このようなドキュメントを定義できるようにするため、マイクロソフトは XML Paper Specification (XPS) を開発しました。WPF は、開発者が XPS ドキュメントの作成および操作に使用できる一連のアプリケーション プログラミング インターフェイス (API) も提供します。

最新のユーザー インターフェイスの作成には、多様なテクノロジを統合する以上のことが関係します。たとえば、最新のグラフィックス カードをいかに利用するかという点があります。WPF はシステムに搭載されているグラフィックス プロセッシング ユニット (GPU) を可能な限り活用します。また、ビットマップ グラフィックスの限界を取り払うことも関係します。WPF はベクタ グラフィックスのみを使用するので、表示画面のサイズと解像度に応じて画像を自動的にサイズ調整することができます。そのため、開発者は小さなモニタ用と大画面テレビ用に異なるグラフィックスを作成する必要がなくなります。このような処理は、WPF に任せることができます。

ユーザー インターフェイスの作成に必要なすべてのテクノロジを 1 つの基盤に統合することにより、WPF はインターフェイスを作成する技術者の負担を大幅に軽減します。技術者は 1 つの環境についてのみ習得すればよいので、アプリケーションの作成と維持管理にかかるコストを抑えることができます。グラフィックスやビデオなどを組み込んだインターフェイスが簡単に構築できるので、Windows アプリケーションとユーザーとの対話の質を向上し、同時にビジネス価値も高めることができます。

開発者とデザイナのコラボレーション

多様な機能を備えたユーザー インターフェイスを作成するうえで、統合テクノロジ基盤は大きな強みとなります。しかし、開発者がこの強みを十分に活かし、わかりやすく使い勝手の良いインターフェイスを作成できると期待するのはあまり現実的ではありません。効果的なユーザー インターフェイス、特に病院の例で示したような総合的なインターフェイスを作成するには、多くの場合ソフトウェアの専門家が持つ以上のスキルが必要となります。多くのアプリケーションは開発者だけで構築されますが、質の高いユーザー インターフェイスを構築するには実際のところ専門のインターフェイス デザイナの協力が必要です。

しかし、デザイナと開発者はどうすればスムーズに連携できるのでしょうか。分野の異なるこれらの専門家が共同で作業するため現在採用されているプロセスには多くの問題点があります。一般に、デザイナはグラフィカル ツールを使用して、アプリケーションで表示される画面レイアウトの静止画像を作成します。デザイナはこれらの画像を開発者に渡し、開発者はそれらの画像を基に実際のコードを作成します。しかし、デザイナが簡単に作図できるインターフェイスであっても、開発者が実装するのは難しい、あるいは不可能というケースがあります。たとえば、テクノロジの限界、タイトなスケジュール、スキルの不足、解釈の誤り、または単純な意見の相違によって、開発者はデザイナの意図を十分に反映できない場合があります。したがって今必要とされているのは、これら異なる 2 つの分野の専門家がインターフェイスの質を損なわずに、協力し合うことのできる環境を整えることです。

この問題を解決するため、WPF では eXtensible Application Markup Language (XAML) を導入しました。XAML は、Button、TextBox、Label など数多くの XML 要素セットを定義して、ユーザー インターフェイスがどのように表示されるかを厳密に定義します。XAML 要素には、通常さまざまなオプションを設定できる属性があります。たとえば、次の単純な XAML コードでは "No" という語が表示された赤いボタンが作成されます。

<Button Background="Red">
 No
</Button>

各 XAML 要素は WPF クラスに対応し、要素の各属性はクラスのプロパティかイベントに対応します。たとえば、この赤いボタンは次のような C# コードでも作成できます。

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

XAML で記述できるものがすべてコードでも記述できるのであれば、XAML を使用する理由はどこにあるのでしょうか。XML ベースの記述ファイルを生成および処理する構築ツールを使用すると、コードを使用する場合よりもスムーズに作業を進められるというのがその理由です。XAML により、ツールで処理しやすい形式でユーザー インターフェイスを記述できるので、開発者とデザイナはスムーズに連携できます。次の図に、共同作業のプロセスを示します。

introducingwpf4.png

図 4: XAML により可能となるデザイナと開発者のコラボレーション  

デザイナは、Microsoft Expression Interactive Designer (訳注: Microsoft Blend という名前に変更) などのツールを使用してユーザー インターフェイスの外観や対話方式を指定できます。WPF インターフェイスのルック アンド フィールを定義するために開発されたこのツールは、インターフェイスの記述ファイルを XAML 言語で生成します (XAML の記述には、この文書に例として掲載したような単純なボタンも含まれますが、実際の XAML 記述ファイルはこのボタンのコードより複雑です)。開発者は、XAML で記述されたファイルを Microsoft Visual Studio などのツールにインポートします。開発者はデザイナが作成した静止画像に基づくインターフェイスをゼロから作成する必要はありません。インターフェイスの定義をそのまま採用することができるのです。次に、開発者はインターフェイスのコードを記述し、イベント ハンドラや、その他アプリケーションで必要となる機能を作成します。アプリケーションのインターフェイスに汎用的に適用できるスタイルを作成し、状況に応じて必要なカスタマイズを加えることもできます。

デザイナと開発者のシームレスなコラボレーションを実現することにより、デザイナが作成した画像からインターフェイスを実装する際に発生しがちな解釈ミスを少なくすることができます。また、デザイナと開発者が平行して作業することが可能になるため、短いイテレーションを繰り返し、効果的なフィードバックを行うことができます。加えて、両者が同じ構築システムを使用するため、これら 2 つの開発環境の間で WPF アプリケーションを受け渡しすることもできます。また、XAML 定義のインターフェイスをデザインする特殊なツールも使用できます。たとえば、Electric Rain の ZAM 3D を使用すると、3D のインターフェイス要素を作成できます。

質の高いユーザー インターフェイスは生産性を向上します。これは、いたって有用なビジネス価値を有しています。ただし、WPF の多面的世界で効果的なインターフェイスを作成するには、デザイナはプロセスにおいて第一級市民とならなければなりません。XAML および XAML をサポートするツールの主要な目標は、これを可能にすることです。

Windows および Web ブラウザ ユーザー インターフェイスの共通テクノロジ

Windows アプリケーションには、効果的なユーザー インターフェイスを作成しなければなりません。しかし、Web ベースのアプリケーション用に効果的なインターフェイスを作成することも、それに劣らず重要といえます。Web ブラウザ ユーザー インターフェイスとも呼ばれるように、このインターフェイスは Web ブラウザによって提供されます。最も単純な形式の場合、ブラウザは受信した HTML をそのまま表示します。応答性に優れたブラウザのインターフェイスでは、通常 Asynchronous JavaScript and XML (AJAX) を使用して、JavaScript で実行されるロジックが提供されます。インターフェイスの中には、Adobe の Flash Player やその他のテクノロジを使用してアニメーションやビデオなどをサポートするものもあります。このような多様な機能を備えたインターフェイスを提供する Web ソフトウェアは、リッチ * * インターネット * * アプリケーション と呼ばれ、ユーザー エクスペリエンスを大幅に向上します。また、より魅力的な Web アプリケーションを提供することにより、ビジネス価値を大きく向上します。

従来 Web ブラウザ インターフェイスの構築には、ネイティブ Windows インターフェイスで使用されるものとはまったく異なるテクノロジ セットが使用されてきました。そのため、開発者は通常 Windows インターフェイスの開発か Web インターフェイスの開発のいずれかに特化して作業を行わざるを得ませんでした。しかし、Windows からアクセスされるリッチ インターネット アプリケーションの場合、このような区分にはもはや意味がありません。ネイティブ Windows インターフェイスと Web ブラウザ インターフェイスの構築に同じテクノロジを使用できないという本質的な理由など存在しないのです。

WPF は、このような区分を取り払います。開発者は WPF を使用して Internet Explorer で実行される XAML ブラウザ アプリケーション (XBAP) を作成できます。スタンドアロン WPF アプリケーションと XBAP は、実際に同じコードを使用して作成できます。次の画面は、スタンドアロン Windows アプリケーションとして実行される金融サービス アプリケーションの画面です。前述の病院のアプリケーションと同様、このインターフェイスにはテキスト、画像、さまざまなタイプのグラフィックスなどが混在しています (このウィンドウの背後に表示されているのは Windows Vista デスクトップです。時計などのガジェットや、アプリケーション ウィンドウの枠を半透明にする Aero テーマが表示されています)。

introducingwpf5.png

図 5: 金融サービス   アプリケーションはスタンドアロン WPF アプリケーションとして実行できる  

次に、このインターフェイスを XBAP として Internet Explorer で実行する場合の画面を示します。

introducingwpf6.png

図 6: 同じアプリケーションを XBAP として実行することも可能  

インターフェイスは、アプリケーションのウィンドウではなく、ブラウザのウィンドウ内で実行されていますが、まったく同じように機能します。どちらの場合でも同じコードが使用できるので、両方のタイプのインターフェイスを準備する作業が軽減されます。同じコードを使用できるということは、同じ開発スキルを使用できるということでもあります。開発者を Windows インターフェイス開発者や Web インターフェイス開発者というカテゴリに無理やり分類する必要はなくなります。WPF はこのような境界を打ち崩し、どちらのインターフェイスの開発にも同じスキルを活かせるようにします。

Windows インターフェイスと Web インターフェイスの作成に同じテクノロジを使用できることのもう 1 つの利点は、どちらのタイプのインターフェイスに重きを置くのか、アプリケーションの作成時に決定しなくてもよいという点です。ターゲットとなるクライアントが XBAP を実行するための要件を満たしている限り、ほぼ同じコードを使用して Windows インターフェイスと Web インターフェイスのいずれか (あるいは両方) を提供できます。

XBAP は Web サーバーからオン デマンドでダウンロードされるため、スタンドアロン Windows アプリケーションより厳しいセキュリティ要件を満たさなければなりません。そのため、XBAP は .NET Framework のコード アクセス セキュリティによって提供されるセキュリティ サンドボックス内で実行されます。また、XBAP は WPF がインストールされた Windows システムの Internet Explorer バージョン 6 および 7 以外では実行できません。ただし、これらの要件を満たしていれば、リッチ インターネット アプリケーションはスタンドアロン Windows アプリケーションと同じ基盤を使用できます。

Windows Presentation Foundation の使用

WPF がどのような問題の解決に役立つのかを知ることは大切ですが、どのようにそれらの問題が解決されるのかその仕組みを知ることも大切です。ここでは、WPF のテクノロジそのものを概観し、Windows デスクトップ アプリケーション、XBAP、および XPS ドキュメントでそれぞれどのようにこのテクノロジが適用されているのかを探ります。

Windows Presentation Foundation のテクノロジ

WPF はユーザー インターフェイス作成のために統合された基盤を提供しますが、ここでは WPF に含まれるテクノロジをわかりやすくパーツに分けて考察します。これらのパーツには、ドキュメント、画像、グラフィックス、アニメーションなどがあります。これらすべては WPF の基本的なアプリケーション モデルに依存しています。まずは、このアプリケーション モデルについて説明します。

アプリケーション モデル

.NET Framework の他のコンポーネントと同様、WPF の機能は名前空間の 1 つのグループにまとめられ、System.Windows 名前空間に含まれます。どの機能を使用する場合でも、WPF アプリケーションの基本構造はほとんど変わりません。スタンドアロン Windows アプリケーションか XBAP かにかかわらず、アプリケーションは通常 XAML ページのセットと、それらのページに関連付けられたコードによって構成されます。

ルートでは、すべてのアプリケーションが WPF の標準クラスである Application を継承します。このクラスは、すべてのアプリケーションで使用される一般的なサービスを提供します。これには、ステートを維持してアプリケーション全体で使用できるようにすることや、アプリケーションを起動する Run、アプリケーションを終了させる Shutdown などの標準メソッドを提供することが含まれます。

Application オブジェクトは、Application 要素を介して XAML で作成するか、Application クラスを使用してコードで作成することができます (WPF では、ほぼ例外なくこれら 2 つの方法が使用できますが、説明を簡潔にするため、この文書では常に XAML を使用する方法を採用しています)。次に XAML の簡単な記述の例を示します。

<Application xmlns=   
    "http://schemas.microsoft.com/winfx/2006/xaml/presentation"
              xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
     StartupUri="Page1.xaml"
     x:Class="Example.SimpleApp">
. . . 
</Application>

この定義では、まずこの要素の既定値として WPF の名前空間が指定され、次に XAML 名前空間の接頭辞が定義されています (XAML は WPF 以外でも使用されるため、これら 2 つの名前空間は同義ではありません)。続いて、アプリケーションの起動時にロードおよび表示される XAML ページの名前が StartupUri 属性を使用して指定されています。最後に、属性 Class を使用して、このアプリケーションと関連付けられたコードが格納されているクラスが指定されています。前述のように、通常 WPF アプリケーションには XAML と C# や Visual Basic で記述されたコードの両方が含まれるため、このクラスのコードはコードビハインド ファイルに格納されます。開始 Application タグの後には、アプリケーションを定義する残りの XAML が記述され (ここでは省略)、最後に Application 要素の終了タグが挿入されます。

すべての WPF アプリケーションは同じルート クラスから派生しますが、開発者の選択に任されている点も数多くあります。中でも重要なのは、従来のダイアログ駆動型インターフェイスかナビゲーション インターフェイスのいずれを提供するかという選択です。ダイアログ駆動型インターフェイスは、Windows ユーザーが見慣れているボタンなどの要素を表示します。一方、ナビゲーション インターフェイスは、ブラウザに似た動作をします。たとえば、このインターフェイスは一般に、新しいウィンドウを開いてダイアログを表示することはせず、新しいページをロードします。このタイプのインターフェイスはページのグループとして実装され、各ページには XAML で定義されたユーザー インターフェイスとプログラミング言語で記述されたロジックが含まれます。HTML で定義されたブラウザ ページと同様に、XAML の Hyperlink 要素を使用して、ページをリンクすることもできます。また、Web ベース アプリケーションのページと同様に、ユーザーは履歴の一覧を参照しながら、これらのページを移動することができます。これではブラウザと勘違いしてしまいそうですが、あくまでもこれは Windows アプリケーションです。XBAP では主にこのナビゲーション インターフェイスが使用されると予想されますが、スタンドアロン Windows アプリケーションにおいてもナビゲーション インターフェイスを介してユーザーと対話することが可能です。どちらのインターフェイスを選択するかは、アプリケーションの作成者が決定します。

アプリケーションで使用されるインターフェイスのスタイルにかかわらず、アプリケーションでは少なくとも 1 つ以上のウィンドウが表示されます。WPF では、ウィンドウの表示方法に関してもいくつかの選択肢があります。基本的なウィンドウ機能 (表示、非表示、閉じるなど) を提供する単純な Window クラスは、通常、ナビゲーション インターフェイスを実装しない WPF アプリケーションで使用されます。ナビゲーション インターフェイスを実装するアプリケーションで使用される NavigationWindow は、基本的な Window クラスを拡張して、ナビゲーションをサポートします。このサポートには、アプリケーションが新しいページに移動できるようにする Navigate メソッド、ユーザーのナビゲーション履歴を記録するジャーナル機能、およびさまざまなナビゲーションに関連するイベントがあります。

レイアウトとコントロール

WPF アプリケーションでは、レイアウトのパネル を使用してインターフェイスのさまざまな要素を整理します。各パネルには、コントロール (ボタン、テキスト ボックス、他のパネル) などの子要素を格納できます。異なるタイプのパネルには、異なるレイアウト オプションがあります。たとえば、DockPanel では子要素をパネルの縁に沿って配置しますが、Grid では、その名のとおり子要素を正確にグリッド上に配置します。開発者は、グリッドの行と列の数を定義して、子要素を配置する正確な場所を指定できます。Canvas では、パネルの境界内の任意の場所に子要素を配置できます。

他のユーザー インターフェイス テクノロジと同様、WPF には豊富なコントロール セットが用意されており、カスタム コントロールの作成もサポートされています。標準セットには、Button、Label、TextBox、ListBox、Menu、Slider、またユーザー インターフェイスのデザインで一般的に使用される他の要素が含まれています。加えて、SpellCheck、PasswordBox、インクを操作するコントロール (タブレット PC で使用される) など、高度な機能を持つコントロールもあります。

通常のグラフィカル インターフェイスと同様、ユーザーが引き起こすイベント (マウス操作やキー入力など) は、WPF アプリケーションのコントロールによって検出し、処理することができます。コントロールや他のユーザー インターフェイス要素が完全に XAML のみで指定できるのに対し、イベントはコードで処理しなければなりません。たとえば、Canvas に配置される単純な Button を XAML で定義すると次のようになります。

<Canvas xmlns=
   "http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="Example.CodeForCanvas">
  <Button Click="Button_Click">
   Click Here
  </Button>
</Canvas>

開始 Canvas タグでは、まず通常どおり WPF と XAML の名前空間が定義されます。次に、この XAML と関連付けられたコードが .NET Framework の名前空間 Example の CodeForCanvas というクラスに格納されていることが示されています。続く Button の定義では、画面に表示されるテキスト "Click Here" が指定されています。開始 Button タグの Click 属性は、このボタンが Button_Click というメソッドに依存して、クリック イベントを処理することを示しています。メソッドのコードは、次のようになります。

namespace Example {
  public partial class CodeForCanvas : Canvas  {
    void Button_Click(object sender, RoutedEventArgs e)    {
      Button btn = e.Source as Button;
      btn.Background = Brushes.Purple; 
    }
  }
}

名前空間とクラス名は、先ほどの Canvas タグで指定されているものと同じです。CodeForCanvas クラスは、WPF によって提供される Canvas 基本クラスから派生し、パーシャル クラスとして定義されています。パーシャル クラスは .NET Framework 2.0 に新たに追加された機能であり、別個に定義されたコードを単一のクラスにマージすることができます。この場合、XAML で定義された Canvas によって生成されるパーシャル クラスが、コードで定義されたこのパーシャル クラスと結合されます。その結果、ボタンを含むキャンバスの表示とイベント処理の両方を実行できる 1 つの完全なクラスが作成されます。

イベントを処理する Button_Click メソッドは、CodeForCanvas クラス内で提供されます。イベントの処理は .NET Framework の標準規則に従って行われます。ただし、イベントの引数は WPF で定義された RoutedEventArgs クラスを使用して渡されます。このクラスの Source プロパティにはイベントを生成した Button への参照が含まれており、メソッドはこの参照を使用してボタンの色を紫に変えます。

この簡単な例でも示されているように、WPF ユーザー インターフェイスの要素はビジュアル ツリーという構造をとります。この例の場合、ツリーは Canvas とその唯一の子要素である Button だけで構成されていますが、実際の WPF アプリケーションでは通常ツリーの構造がさらに複雑になります。ユーザー インターフェイスを実際に作成する際には、このビジュアル ツリーをレンダリングする必要があります。可能な場合は、ハードウェア レンダリングを使用して、アプリケーションのコンピュータにインストールされているグラフィックス カードにレンダリング処理が任せられます。コンピュータのグラフィックス ハードウェアにその処理能力がない場合、WPF は自身のソフトウェアを使用してインターフェイスをレンダリングします。どちらを使用するかは、実行時に WPF によって決定されます。開発者が何か特別な処理を行う必要はありません。

レンダリングがハードウェアで行われるかソフトウェアで行われるかにかかわりなく、WPF は常に保持モード グラフィックスと呼ばれるアプローチを使用します。アプリケーションの作成者は、ビジュアル ツリーの構造を XAML とコードの組み合わせなどを使用して定義します。WPF は、定義されたこのツリーに情報を保持します。たとえば、ユーザーがウィンドウを再表示するとき、アプリケーションがそのウィンドウの全部あるいは一部を再描画しなくても、WPF がその処理を行います。ツリーを構成する要素は画面上のピクセルとしてではなくオブジェクトとして保存されているので、WPF にはこのようなレンダリングを処理するための十分な情報があるのです。ウィンドウやウィンドウ内のコントロールがサイズ変更される場合も、WPF はすべての再レンダリング処理を実行できます。WPF はグラフィックスの形状 (直線、楕円など) を認識し、ピクセル マップではなくベクタ グラフィックスを使用するため、インターフェイスを新しいサイズで再描画するための十分な情報を保持できます。

スタイルとテンプレート

一度定義したユーザー インターフェイス要素の外観を他の要素にも適用できれば、非常に便利です。HTML ページでは、この機能が Cascading Style Sheets (CSS) によって実現されています。WPF では、スタイル によって同じような機能が提供されます。CSS スタイルシートが広く使用されていることからも明らかですが、スタイルの定義は便利な機能です。この機能によって、デザイナと開発者は適切に仕事を分業できます。たとえば、インターフェイスに統一感を持たせる外観はデザイナによって作成されるので、開発者は細かいディテールに注意を払う必要がなくなります。

WPF アプリケーションの作成者は、XAML の Style 要素を使用してある要素の外観の特徴を 1 つ以上定義し、そのスタイルを他の要素に何度でも適用することができます。たとえば、ButtonStyle というスタイルは次のように定義できます。

<Style x:Key="ButtonStyle">
  <Setter Property="Control.Background" Value="Red"/>
  <Setter Property="Control.FontSize" Value="16"/>
</Style>

このスタイルを使用して定義されるボタンは、赤い背景を持ち、16 フォント サイズを使用します。このスタイルは、たとえば次のように適用できます。

<Button Style="{StaticResource ButtonStyle}">
   Click Here
  </Button>

この例で "StaticResource" と記述されているように、WPF のスタイルは通常リソースとして定義されます。リソースとは、アプリケーションのコードとは別個に定義されたデータを指します。

スタイルには、このような単純な例よりも高度な利用方法があります。たとえば、1 つのスタイルから別のスタイルを派生させることが可能です。このとき、他のスタイルの設定を継承したり、場合によっては上書きしたりすることができます。また、スタイルでトリガ を定義して、対話的な動作の一般的な特徴を指定することもできます。たとえば、ボタンの上にマウスを置くとボタンの背景が黄色に変化するよう指定することができます。

WPF では、テンプレート の使用もサポートされています。テンプレートはスタイルに似ていますが、次の 2 つのタイプがあります。

  • データ テンプレート: XAML の DataTemplate 要素を使用して、データの表示方法の特徴をセットとして指定できます。色や配置などをデータ テンプレートで一度定義しておくと、アプリケーションのユーザー インターフェイスの他の場所で使用することができます。

  • コントロール テンプレート: XAML の ControlTemplate 要素を使用して、コントロールの外観を定義できます。

インターフェイスの外観を簡単に定義できる機能をアプリケーションの作成者が必要とするのは当然のことです。WPF では、主にスタイルとテンプレートによってこの機能を提供しています。

テキスト

テキストがまったく表示されないユーザー インターフェイスなど、ほとんど存在しません。インターフェイスによっては、テキストしか表示されない場合もあります。しかし、多くのユーザーは印刷されたページと比べて、画面上のテキストは読みづらいと感じています。ユーザーは本や雑誌などで美しく整った活字を見慣れています。そのため、それらの文字を画面上で見ると、何かが違うように感じます。どこか読みにくく思うのです。

WPF は、このような違和感を解消し、印刷ページのように読みやすいテキストを画面上に再現することを目指しています。この目標達成のため、WPF は、業界標準の OpenType フォントをサポートして、既存のフォント ライブラリを使用できるようにしています。さらに、WPF は最新のテクノロジである ClearType もサポートしています。サブピクセル ポジショニングは、最新のディスプレイ画面で各ピクセルを構成する個々のサブ要素を明るくできる技術です。ClearType でこの技術を使用すると、テキストは人の目に、より滑らかに映ります。加えて、WPF では Glyphs クラスを介するテキスト レンダリングに対しても低レベルのサポートを提供しています。この点については後述しますが、XPS ドキュメントはこのクラスを使用してテキストを表現しています。

読みやすさをさらに改善するため、WPF には合字などの機能も追加されています。合字とは、複数の文字を 1 つに結合されたイメージで置き換える機能です。たとえば、印刷ページでは通常 "ffi" という文字の組み合わせが、これら 3 つの文字を結合した 1 つの合字に置き換えられます。画面上で合字を使用すると、どこが変化したのかはっきりわからなくても、ユーザーは見慣れたテキストに親近感を覚えます。

ドキュメント

テキストを読みやすくすることは重要です。テキストはボタンやリストなどユーザー インターフェイスのさまざまな場所に表示されるからです。とはいえ、テキストの読みやすさが最も気になるのは、ドキュメントのように長いテキストを読む場合です。したがって、画面上の読みやすさを改善するには、ドキュメントの表示を改善する必要があります。この目的を達成するため、WPF では固定 ドキュメントとフロー ドキュメントという 2 種類のドキュメントをサポートしています。

固定ドキュメントは、画面またはプリンタのどちらでも同じように出力されます。ある種の書類や法的文書、その他の印刷物では、ドキュメントが常に同じ体裁を保つことが重要です。したがって、固定書式ドキュメントは多くの場合に役立つ重要な機能です。WPF によってサポートされている固定書式ドキュメントは、後述する XPS で定義されます。固定ドキュメントの内容は、XAML の FixedDocument 要素で指定できます。このシンプルな要素には、PageContent 要素のリストだけが含まれており、各 PageContent 要素には、固定ドキュメントのページ名が含まれます。固定ドキュメントの表示には、WPF の DocumentViewer コントロールが使用されます。このコントロールにより、XPS ドキュメントが読み取り専用で表示されます。ユーザーは、ドキュメント内でページの移動や特定のテキストの検索など、さまざまな操作を行うことができます。

固定ドキュメントが画面上および紙面上での使用を前提にしているのに対して、フロー ドキュメントは画面上での使用だけを前提にしています。ドキュメントの内容をできるだけ読みやすくするため、フロー ドキュメントでは、ウィンドウのサイズや他の要因に基づいて、ドキュメントのテキストやグラフィックスの表示方法を調整できます。フロー ドキュメントは、FlowDocument と呼ばれる XAML 要素で定義されます。次に、簡単な例を示します。

<FlowDocument 
    ColumnWidth="300" 
    IsColumnWidthFlexible="True" 
    IsHyphenationEnabled="True">
      <Paragraph FontSize="12">
       <Bold>Describing WPF</Bold>
      </Paragraph>
      <Paragraph FontSize="10">
       WPF is the user interface technology for the .NET 
       Framework 3.0. It provides a unified foundation for modern 
       user interfaces, including support for documents, two- and 
       three-dimensional graphics, media, and more. It also 
       allows using the same approach (and the same code) for 
       creating standalone Windows applications and applications 
       that run inside a browser.
      </Paragraph>
  </FlowDocument>

このドキュメントは、300 以上の列幅で表示されます (幅はデバイス依存のピクセル で算出され、1 ピクセルは 96 分の 1 インチです)。一方、次の行では、IsColumnWidthFlexible プロパティが true に設定されており、列幅がフレキシブルになっています。これにより、WPF はドキュメントの表示に使用する列幅と列数を変更できるようになります。たとえば、ユーザーがこのドキュメントを表示するウィンドウの幅を変更すると、WPF はドキュメントのテキスト表示に使用する列幅と列数を増減して調整します。

次に、IsHyphenationEnabled プロパティが true に設定されており、ハイフンでつなぐことが要求されています。この後に続くのが、このドキュメントの内容である 2 つの段落です。各段落のテキストはParagraph 要素内に含まれており、それぞれでフォント サイズが設定されています。最初の段落のテキストには、太字も指定されています。

WPF には、読みやすさを向上するための FlowDocument オプションがいくつか用意されています。たとえば、IsOptimalParagraphEnabled プロパティを true に設定すると、段落全体で文字間のスペースが可能な限り均等になります。これにより、印刷物で一般的に行われているように、読みやすさを損なうスペースの "リバー" を防ぐことができます。フロー ドキュメントでは、注釈を付けて、通常のテキストやタブレット PC のインクによるメモを追加できます。各注釈は、その注釈が関連付けられているドキュメント内の場所を示すアンカー と、その注釈自体の内容を含むカーゴ で構成されます。

FlowDocument を表示するため、WPF にはいくつかのコントロールが含まれています。それらのコントロールは次のとおりです。

  • FlowDocumentPageViewer: ドキュメントを一度に 1 ページずつ移動できるようにします。このコントロールにより、戻るおよび進むボタンと、表示しているドキュメントのサイズを調整するためのズーム コントロールが提供されます。

  • FlowDocumentScrollViewer: FlowDocument で通常のスクロール表示を行います。ページの右側にはスクロール バーが表示されます。

  • FlowDocumentReader: FlowDocumentPageViewer と FlowDocumentScrollViewer 両方の機能を組み合わせます。このコントロールにより、ユーザーはフロー ドキュメントのページ表示 (一度に 2 ページ表示する機能を含む) とスクロール表示を切り替えることができます。

ますます多くの情報がデジタルで提供されるにしたがって、画面での読みやすさの改善はさらに重要になっています。フロー ドキュメントで状況に合った表示方法を提供することにより、WPF は Windows ユーザーが快適にドキュメントを参照できるようにします。

画像

企業ロゴであれ、サンセットの写真であれ、画像はユーザー インターフェイスで重要な部分を担います。通常、WPF では画像が Image コントロールによって表示されます。たとえば、JPEG ファイルを表示する場合、次の XAML を使用できます。

<Image 
 Width="200" 
 Source="C:\Documents and Settings\All Users\Documents\
  My Pictures\Ava.jpg" />

画像の幅は 200 に設定されています。この場合も、単位にはデバイス依存のピクセルが使用されます。画像を含むファイルは、Source 属性で識別されます。

画像ファイルには、ユーザーによって設定されたキーワードやレイティングなど、画像に関する情報 (メタデータ) を含むことができます。これらの情報は、WPF アプリケーションで読み書きすることができます。さらに、画像はさまざまな仕方で活用できます。たとえば、回転する 3D オブジェクトの各面に画像を描くことができます。ここで挙げられている例は、一般的な使用を示す簡単なものですが、WPF では多彩な方法で画像を活用することができます。

WPF Image コントロールでは、JPEG、BMP、TIFF、GIF、PNG など、さまざまなフォーマットで保存されている画像を表示できます。さらに、Windows Vista で新たに搭載されるマイクロソフトの Windows Media Photo (WMPhoto) フォーマットで保存されている画像も表示できます。どのフォーマットでも、WPF は画像の表示に Windows Imaging Component (WIC) を使用します。前述の画像フォーマット全種のコーダー/デコーダー (コーデック と呼ばれる) に加えて、WIC にはサードパーティのコーデックを追加するためのフレームワークも用意されています。

ビデオとオーディオ

ネットワークとプロセッサが高速化するにしたがって、ソフトウェアとの対話にビデオを使用する機会がますます増えています。さらにコンピュータで音楽や他のオーディオを楽しむユーザーも増えています。この時代の流れに対応すべく、WPF はビデオとオーディオの両方をビルトインでサポートしています。

ビデオとオーディオのサポートには、MediaElement コントロールが使用されます。次に、このコントロールの使用方法を示す簡単な XAML の例を示します。

<MediaElement 
 Source="C:\Documents and Settings\All Users\Documents\
  My Videos\Ruby.wmv" />

このコントロールで、WMV、MPEG、および AVI に加えて、さまざまなオーディオ フォーマットを再生できます。

2D グラフィックス

過去 20 年間にわたり、Windows の 2D グラフィックス クリエータは、Graphics Device Interface (GDI) とその後継である GDI+ を使用してきました。にもかかわらず、Windows フォーム アプリケーションでは、明確に区別された名前空間を介して、この機能にアクセスしなければなりませんでした。つまり、2D グラフィックスがユーザー インターフェイス テクノロジ自体に統合されていなかったのです。3D グラフィックスになると、さらに大変です。3D グラフィックスには、まったく別のテクノロジである Direct3D が必要だからです。しかし、WPF により、この煩雑さから解放され、アプリケーションの大部分を共有できるようになります。2D と 3D グラフィックスの両方が、WPF ライブラリを使用して、XAML またはコードで直接作成できます。WPF に含まれる他の要素と同様に、2D および 3D グラフィックスで使用される要素もアプリケーションのビジュアル ツリーを構成します。

2D グラフィックスの場合、WPF はシェイプ のグループを定義します。アプリケーションは、このグループを使用して画像を作成できます。次のクラスがあります。

  • Line: 2 点間の直線を描画します。

  • Ellipse: 楕円を描画します。

  • Rectangle: 長方形を描画します。

  • Polygon: 連続する直線のグループで定義される、閉じられたシェイプを描画します。

  • Polyline: 連続する直線のグループで定義される、閉じられていないシェイプを描画します。

  • Path: 任意のパスで指定されるシェイプを描画します。シェイプは、閉じることも開くこともできます。また、パスの線には直線または曲線を使用できます。実際、直線、楕円、長方形、ポリゴン、ポリライン、その他さまざまなシェイプは Path で描画できるので、他のクラスはすべて開発者の便宜を図るために用意されています。

これらのクラスを使用することにより、シンプルなグラフィックスを直観的に作成できます。たとえば、次の XAML は赤い楕円を描画します。

<Ellipse Width="30" Height="10" Fill="Red" />

シェイプを塗りつぶすには、ブラシ を使用します。上記の例では、デフォルトの単一色のブラシが使用されています。もちろん、WPF には他のオプションも用意されています。たとえば、長方形の色を水平方向に赤から黄色へグラデーションする場合は、次のように定義できます。

<Rectangle Width="30" Height="10" 
 Fill="HorizontalGradient Red Yellow" />

垂直方向のグラデーション、円形グラデーション、および画像、ビットマップなどを描画するブラシなど、さまざまなブラシを使用できます。ここでは割愛しますが、シェイプでペン を使用して、輪郭線の色、幅、スタイルを指定することもできます。

WPF について理解しておくべき重要な点は、すべてが共通の基盤上に構築されているため、グラフィックスのさまざまな機能が直観的にまとめられているということです。したがって、アプリケーションで、長方形の中に画像を表示したり、ボタンの中に楕円を配置したりすることが可能です。これにより、2D グラフィックスを、3D グラフィックスやインターフェイスの他の部分と簡単に組み合わせることができます。

シェイプに加えて、WPF には 2D グラフィックスに関係する他のクラス グループもあります。それはジオメトリ です。これらのクラスは、多くの点でシェイプに似ています。Line、Rectangle、Ellipse、および Path などのオプションを持つシェイプと同様に、ジオメトリにも LineGeometry、RectangleGeometry、EllipseGeometry、および PathGeometry などのオプションがあります。これらのクラス間で最大の相違点は、シェイプが目に見える画像の描画に使用されるのに対して、ジオメトリはどちらかというと領域の定義に使用されるという点です。たとえば、円の内側にぴったり合うように正方形の画像をトリミングする場合、その円の境界の指定には EllipseGeometry クラスを使用します。同様に、マウス クリックの検出などに使用されるヒット テスティング領域をアプリケーションで定義する場合は、その領域にジオメトリを指定します。

最後に特筆すべき点として、ここで説明されているすべての機能はビジュアル * * レイヤ と呼ばれる下位レベル インターフェイスの最上位に実装されています。このレイヤを直接使用して、グラフィックス、画像、テキストを作成することが可能です。これはシンプルで高性能なグラフィックスの作成などに役立ちますが、アプリケーションの大部分では、シェイプと WPF 提供のハイレベルな抽象化が使用されます。

3D グラフィックス

2D グラフィックスは、Windows インターフェイスで一般的に使用されるため、WPF で非常に多くのテクノロジが用意されています。一方、3D グラフィックスはデータの可視化、3D チャート、商品の描画などによって大きな価値を生み出せる可能性があるにもかかわらず、現在ではまだ一般的ではありません。従来、3D の処理にはゲーム開発者や他の専門家だけが持つ特殊なスキルが必要とされてきました。WPF は標準的な環境で 3D グラフィックスをサポートすることで、この現状を打破します。

WPF を使用しない場合、Windows の 3D 開発には通常 Direct3D API が使用されます。WPF では 3D グラフィックスの対応として他の機能と同様 Direct3D が使用されますが、開発者からは隠されています。したがって、その開発は非常にシンプルになります。後述のように、依然として WPF よりも Direct3D を使用する方が望ましい場合があるとはいえ、マイクロソフトでは WPF を Windows インターフェイスの主な 3D 開発基盤として位置付けています。

WPF で 3D グラフィックスを表示するには、アプリケーションで Viewport3D コントロールを使用します。基本的にこのコントロールは、アプリケーションが表現する 3D 空間の入り口となります。Viewport3D コントロールは、WPF インターフェイスの任意の場所で使用でき、必要なときはいつでも 3D グラフィックスを表示できます。

3D シーンを作成するには、1 つ以上のモデル を表現する必要があります。その後、それらのモデルがどのように照射および表示されるかを指定する必要があります。例のごとく、これらの設定すべては XAML、コード、またはそれらを組み合わせて指定できます。モデルを表現するため、WPF にはモデルのシェイプを定義する GeometryModel3D クラスが用意されています。モデルを定義できたら、さまざまなマテリアル を適用することで、その外観を制御できます。たとえば、SpecularMaterial クラスを使用するとモデルに光沢が加わり、DiffuseMaterial クラスを使用するとモデルから光沢が除去されます。

使用するマテリアルにかかわらず、モデルをさまざまな方法で照射できます。たとえば、DirectionalLight を使用すると特定の方向から来る光を指定できます。また、AmbientLight を使用するとシーンの中の全モデルに光を均一に当てることができます。最後に、モデルの視点を定義するには、カメラ を指定します。たとえば、PerspectiveCamera では、視点からオブジェクトまでの距離と遠近を指定できます。一方、OrthographicCamera では視点からオブジェクトまでの距離を指定できますが、遠近は指定できません。したがって、カメラからさらに離れているオブジェクトも小さく表示されません。

複雑な 3D シーンを XAML やコードで直接作成することは簡単ではありません。したがって、開発者はほとんどの 3D WPF アプリケーションで、グラフィカル ツールを使用して必要な定義を行うでしょう。開発者がどのような方法で定義を行うとしても、標準ユーザー インターフェイスに 3D グラフィックスを使用することで、ユーザーが目にするインターフェイスの品質を大きく向上することが可能になります。

変形と効果

シェイプや他の要素を定義する機能に加えて、WPF には要素を変形するための機能も用意されており、要素を回転したり、サイズを変更したりできます。これを行うには、XAML で RotateTransform や ScaleTransform 要素を使用します。これらの変形は、ユーザー インターフェイスの任意の要素に適用できます。次に、簡単な例を示します。

</Button>
  <Button Content="Click Here">
   <Button.RenderTransform>
    <RotateTransform Angle="45" />
   </Button.RenderTransform>
  </Button>

RotateTransform 要素により、ボタンが 45 度回転しています。ボタンをこのように回転することがこれといって有用なわけではありませんが、ボタンを回転できるという事実は WPF デザインの持つ汎用性を示しています。ユーザー インターフェイスのさまざまな要素は、雑多な基本テクノロジに依存しないため、それらの要素を多様な方法で組み合わせることができます。

WPF には、事前に定義された効果もいくつかあります。変形と同じように、これらの効果は Buttons や ComboBoxes など、ユーザー インターフェイスのさまざまな要素に適用できます。インターフェイス要素にファジー感を出すぼかし効果や、要素が光って見えるグロー効果、インターフェイス要素の背後に影を追加するドロップ シャドウ効果などがあります。

アニメーション

インターフェイス内の要素に動きを持たせること (アニメーション) は非常に有用です。たとえば、ボタンがクリックに反応して押し込まれてから元に戻るなら、ユーザーはさらにわかりやすいフィードバックを得ることができます。また、さらに高度なアニメーションを使うことで、ユーザーの注意を引いたり、ストーリー性を持たせたりできる魅力的なインターフェイスを作成できます。WPF のアニメーションは、これらを可能にします。

変形の場合と同様、アニメーションはボタン、シェイプ、画像など、インターフェイスのさまざまな要素に適用できます。アニメーションは、一定の時間にわたって、あるオブジェクトの 1 つ以上のプロパティ値を変更することで実現されます。たとえば、2 秒にわたって Ellipse の Height プロパティ値を徐々に小さくすることで、ゆっくりとつぶれる楕円を表示することができます。

多くの場合、関連するアニメーションをグループで定義すると便利です。これを実現するため、WPF には Storyboard クラスが用意されています。各 Storyboard には 1 つ以上のタイムライン を含めることができ、各タイムラインには 1 つ以上のアニメーションを含めることができます。さまざまなタイムラインが用意されており、アニメーションを順序に実行したり、並列で実行したりできます。次は、楕円がつぶれる様子を示す簡単な XAML の例です (一部、省略しています)。

    <Ellipse Width="100" Height="50" Fill="Blue"
     Name="EllipseForSquashing">
     . . . 
     <Storyboard>
      <DoubleAnimation
       Storyboard.TargetName="EllipseForSquashing" 
       Storyboard.TargetProperty="Height"
        From="50" To="25" Duration="0:0:2" />
       </Storyboard>
       . . . 
    </Ellipse>

この例は、前述した Ellipse の定義から始まります。ただし、Name プロパティも使用されており、この Ellipse が後で参照されるように識別子が割り当てられています。詳細な点は省略されていますが、XAML でアニメーションを定義するには Storyboard 要素が必要です。Ellipse の Height プロパティはdouble 型なので、Storyboard に DoubleAnimation 要素が含まれています。この要素は、アニメーションされる Ellipse の名前、変更されるプロパティ、およびその変更内容を指定します。ここでは、2 秒間で Height の値が 50 から 25 に変更されています。

さらに高度なアニメーションを作成することもできます。アニメーションは、マウス クリックなどのイベントがトリガとなって起動されたり、一時停止や再開を行ったり、何回か (または永久に) 繰り返すように設定したりできます。これらすべては、さらにわかりやすいフィードバック、多彩な機能、全体的な使いやすさを備えたユーザー インターフェイスを開発するために用意されています。

データ バインディング

ほとんどのユーザー インターフェイスは、何らかのデータを表示します。これらのインターフェイスを作成する開発者の負担を軽減するため、データ表示を簡単に行えるデータ バインディング（データ連携機能）が用意されています。データ バインディングを使用すると、WPF コントロールが表示する内容を、そのコントロール以外の場所のデータとリンクすることができます。たとえば、WPF TextBox コントロールの Text プロパティの値を、このアプリケーションのビジネス ロジックを構成する Employee オブジェクトの Name プロパティにバインディングできます。どちらのプロパティに変更を加えても、変更内容が互いに反映されます。つまり、ユーザーが TextBox の値を更新すると Employee オブジェクトの Name プロパティも更新され、その逆もまた同様です。

2 つのオブジェクトのプロパティ間でこのようなリンクを作成するには、WPF Binding クラスを使用します。次に、このクラスを使用した XAML の簡単な例を示します。

<TextBox . . . >
 <TextBox.Text>
  <Binding Path="Name" />
 </TextBox.Text>
</TextBox>

この例では、TextBox の Text プロパティのバインディング先プロパティを指定するために、Binding 要素の Path 属性が使用されています。バインディング先プロパティを含むオブジェクト (ランタイムで指定されるオブジェクト) が、C# や Visual Basic などの言語で定義される Common Language Runtime (CLR) オブジェクトである場合、Path が使用されます。CLR オブジェクトと同様、WPF のデータ バインディングは、Binding の XPath プロパティを使用し、直接 XML データにリンクすることもできます。このオプションでは、特定のデータを参照する XML ドキュメントで 1 つ以上のノードを選択する XPath クエリを作成できます。

さらに高度なデータ バインディング オプションも使用できます。たとえば、リスト バインディングでは、標準 IEnumerable インターフェイスを実装する CLR オブジェクトから、ListBox コントロールにデータを挿入することができます。必要に応じて、データは表示する前にフィルタしたり、並べ替えたりすることもできます (ADO.NET Dataset に対するバインディングを行うことも可能ですが、WPF はデータベース (RDBMS: リレーショナル データベース管理システム) のデータに対するバインディングを直接サポートしていません)。どのデータ バインディング オプションを使用するにしても、共通する目的はユーザー インターフェイスのデータ表示をできるだけ簡単に行うことです。

ユーザー インターフェイス オートメーション

言うまでもなく、WPF インターフェイスを最もよく使うのは人間です。しかし、ユーザー インターフェイスが人間ではなく、他のソフトウェアによって操作されなければならない場合があります。WPF のユーザー インターフェイス (UI) オートメーションは、これを可能にします。

たとえば、開発者がインターフェイス用に自動化されたテスト スクリプトを作成する場合について考えてください。UI オートメーションが提供するプログラム アクセスを使用し、開発者はまるで人間がインターフェイスを操作しているかのようなスクリプトを作成できます。さらに、UI オートメーションは、インターフェイスのさまざまな要素を読み上げるツールなど、アクセス補助機能を作成する場合にも便利です。UI オートメーションはインターフェイスの要素を含むツリーをプログラムでウォークするので、このようなツールを作成することが可能になります。

これを実現するため、WPF は UI オートメーション ツリーを作成します。このツリーは AutomationElement オブジェクトで構成され、各オブジェクトはインターフェイス内の要素を表します。ツリーのルートは Desktop で、開いている各アプリケーションがこのルートの子になります。ツリー構造は各アプリケーションへと続き、WPF コントロールそれぞれが 1 つ (場合によっては複数) の AutomationElement オブジェクトとして表されます。また、インターフェイスへの完全なプログラム アクセスを行えるように、ユーザーが対話できるすべての要素は個別の AutomationElement として表されます。たとえば、複数のボタンを含むコントロールでは、そのコントロール自体と各ボタンそれぞれが個別の AutomationElement オブジェクトとして表されます。UI オートメーション ツリーでユーザー インターフェイス要素が詳細に表されることで、テスト スクリプト、アクセス補助機能などのクライアント アプリケーションが、まるで人間のユーザーが行うかのようにインターフェイスの各要素にアクセスできるようになります。

確かに、UI オートメーションは WPF の主要な機能ではありませんし、ほとんどのユーザーにとってこの機能を使う機会は皆無に等しいでしょう。しかし、この機能を本当に 必要とする人、つまりソフトウェア テスターや障害を持つユーザーにとっては欠かすことができない機能です。必ずしも広く使用されていなくても、重要なものがあるのです。

Windows Presentation Foundation の適用

WPF には多彩なテクノロジが実装されています。それらすべてのテクノロジは、ユーザーとの対話に関係しますが、現在ではスタンドアロン WPF アプリケーション、XBAP、および XPS ドキュメントという 3 つの分野にも適用されています。次の節では、これらの 3 つの分野に注目します。

スタンドアロン WPF アプリケーション

WPF を使用する最も一般的な対象は、スタンドアロン アプリケーションです。スタンドアロン WPF アプリケーションは、他の Windows アプリケーションと同様に実行されます。実行に、Web ブラウザは必要ありません。したがって、スタンドアロン アプリケーションには完全信頼が付与され、すべての WPF 機能の使用が許可されます。完全信頼とは、スタンドアロン WPF アプリケーションが、コンピュータ上で利用可能な Windows Communication Foundation (WCF) などの他のサービスを自由に使用できることも意味します。

他の Windows アプリケーションと同様に、スタンドアロン WPF アプリケーションはローカル ディスクまたはネットワーク サーバーからインストールすることができます。また、.NET Framework の機能である ClickOnce を使用してインストールすることもできます。ClickOnce を使用すると、Internet Explorer ユーザーは、WPF アプリケーションなどの Windows アプリケーションのダウンロードとインストール、およびそれらのアプリケーションの自動更新をより容易に行えるようになります。

XAML ブラウザ アプリケーション: XBAP

スタンドアロン WPF アプリケーションでほとんどの機能を使用できるとしても、それが常に最善の選択肢というわけではありません。状況によっては、Windows アプリケーションよりも Web ブラウザで実行されるクライアントの方が望ましい場合があります。このようなクライアントでも、最新のユーザー インターフェイスを使用できるようにするため、WPF で XBAP が用意されています。

次の図が示すように、XBAP は Internet Explorer の内部で実行されます。XBAP は、ASP.NET、JavaServer Pages (JSP)、または他の Web テクノロジで構築された Web アプリケーションのクライアントとして機能します。XBAP から Web アプリケーションへの応答には、HTTP または SOAP を使用できます。どのサーバー プラットフォームが使用されていても、XBAP は常に ClickOnce を介してロードされます。このプロセス中、ユーザーに対してダイアログやプロンプトは表示されません。XBAP は Web ページのようにロードされます。このため、[スタート] メニューや [プログラムの追加と削除] に XBAP は表示されません。

introducingwpf7.gif

図 7: Internet Explorer の内部で実行される XBAP

厳密に必要というわけではありませんが、通常 XBAP はナビゲーション タイプのインターフェイスを表示します。これにより、ユーザーにとって違和感のない、Web クライアントのような操作性が実現されます。Internet Explorer 7 では、XBAP はブラウザ自体の進むおよび戻るボタンを使用します。また、ユーザーがアクセスした XAML ページは、ブラウザの履歴の一覧に表示されます。一方 Internet Explorer 6 の場合、XBAP は XBAP 専用の進むおよび戻るボタンを表示し、履歴の一覧も XBAP 自体で管理されます。XBAP は、実行されている環境を特定し、それに応じて正しい処理を行うので、開発者がブラウザの各バージョンごとにアプリケーションを作成する必要はありません。

XBAP は Web からロードされてブラウザの内部で実行されるため、XBAP には .NET Framework のコード アクセス セキュリティによって、制限された信頼しか付与されません。このため、スタンドアロン WPF アプリケーションでは可能なことでも、XBAP では行えない場合が数多くあります。たとえば、インターネット ゾーンから展開された XBAP は、次の操作を行えません。

  • スタンドアロン ウィンドウを作成すること。

  • アプリケーション定義のダイアログを表示すること。

  • XBAP 自体で [保存] ダイアログを表示すること。

  • 制限された分離ストレージ (IsolatedStorage) を超えてファイル システムにアクセスすること。

  • UI オートメーション クライアントとして機能すること。

  • WCF を使用すること。WCF アプリケーションには完全信頼が付与されている必要があるため、インターネットから展開された XBAP は WCF を使用できません。代わりに、一般的に ASMX として知られる ASP.NET Web サービスを使用し、ロード元の Webアプリケーションと通信することができます。

  • Windows フォーム、Microsoft Foundation Classes (MFC)、またはダイレクト Win32 呼び出しで作成されたユーザー インターフェイス コードを使用すること。後述のように、スタンドアロン WPF アプリケーションはこれら既存のテクノロジすべてと相互作用できますが、XBAP の制限された信頼環境ではそれらのテクノロジの使用は許可されません。

  • アンマネージ コードを使用すること。

前述のように、スタンドアロン WPF アプリケーションと XBAP の両方に、同じコード ベースを使用できます。これを実現するため、開発者は条件付きコンパイル (つまり XBAP では許可されていない機能を ifdef 文の中でラップすること) を使用するかもしれません。XBAP バージョンでは、ドキュメントの表示、2D および 3D グラフィックスの使用、ビデオやオーディオの再生など、スタンドアロン アプリケーションで可能なほとんどの作業を行えます。さらに、XBAP が実行されているマシンで使用可能なグラフィックス ハードウェアを利用することもできます。

XBAP に加えて、XAML だけで構成されるページを Internet Explorer で直接表示することもできます。Loose XAML と呼ばれるこの XAML は、ブラウザで静的なページを表示する場合に便利です。ただし、イベントを処理する場合はコードが必要になるので、XBAP を作成しなければなりません。

XBAP により、開発者はブラウザ アプリケーションでほとんどの WPF 機能を使用できます。さらに、開発者は共通のプログラミング モデルを手にし、スタンドアロン アプリケーションとブラウザ アプリケーションでほとんど同じコードを使用できます。Web アプリケーションのクライアントが最近の Windows プラットフォームで実行される場合、XBAP は理想的な選択肢となるでしょう。

XPS ドキュメント

WPF で使用される固定書式ドキュメントは XPS ドキュメントと呼ばれ、ユーザー インターフェイスにおける一定の役割を担います。そして、前述のように、WPF には XPS ドキュメントを表示するための DocumentViewer コントロールが用意されています。とはいえ、このコントロールが WPF に含まれるというのはわかりますが、XPS 自体が WPF に含まれるべき理由がはっきりしません。結局のところ、XPS 仕様では固定書式ドキュメントを定義するための詳細な方法が提供されており、ドキュメント自体もさまざまな方法で使用できます。対照的に、WPF の他の要素はユーザー インターフェイスの作成に特化しています。このように考えると、なぜ XPS を WPF の一部と見なす必要があるのかという疑問が生じます。

その大きな理由の 1 つとして、XPS ドキュメントが XAML で定義されているという点があります。確かに、XPS ドキュメントでは、レイアウトを定義する Canvas 要素、テキストを表現する Glyphs 要素、2D グラフィックスを作成する Path 要素のように、限られた数の XAML しか使用されていません。しかし、XPS ドキュメントは実際には XAML ドキュメントです。こう考えると、XPS が WPF の一部というのも一理あります。

とはいえ、XPS が最も活躍する場は、画面上のユーザー インターフェイスではありません。Windows Vista 以降、XPS は Windows のネイティブな印刷フォーマットになりました。XPS はページ記述言語として機能するため、XPS ドキュメントは XPS 対応プリンタで直接レンダリングすることができます。これにより、画面からプリンタに至るまで単一の記述フォーマット、つまり XAML を使用できます。さらに、XPS により、既存の Windows GDI ベースの印刷メカニズムでパフォーマンスが向上し、透明度や階調度などの高度なグラフィック効果の印刷品質を改善できます。

XAML と同様に、XPS ドキュメントにはさまざまなフォーマットの画像 (JPEG、PNG、TIFF、および WMPhoto を含む)、フォント データ、ドキュメント構造情報などのバイナリ データを含めることができます。さらに、必要に応じて W3C XML Signature 定義と X.509 証明書を使用し、XPS ドキュメントをデジタル署名することもできます。各 XPS ドキュメントは、その中に何が含まれているかにかかわらず、Open Packaging Conventions (OPC) で定義されたフォーマットで保存されます。OPC は、XML ドキュメント (XPS または XAML ドキュメントだけではない) のさまざまな部分がどのように関連しているか、またそれらの部分が標準的な ZIP フォーマットでどのように保存されているかなどを指定します。Microsoft Office 2007 も XML フォーマットに OPC を使用しており、両方のドキュメント間で一定の共通性を維持しています。

WPF アプリケーションのユーザーは、前述のように WPF DocumentViewer コントロールを使用して XPS ドキュメントを表示できます。マイクロソフトは、次に示すような DocumentViewer コントロール上に構築された XPS ビューア アプリケーションも提供します。コントロールと同様に、このアプリケーションでもドキュメントをページごとに表示したり、テキストを検索したり、さまざまな操作が行えます。XPS ドキュメントは Windows 固有のものではないため、マイクロソフトは Apple Macintosh などの他のプラットフォーム向けにも XPS ビューアを提供する予定です。

introducingwpf7.gif

図 8: XPS ビューアにより、 XPS ドキュメントを一度に 1 ページずつ表示することが可能  

開発者が XPS ドキュメントを処理できるように、WPF には XPS ドキュメントを作成、ロード、操作するための API セットが用意されています。WPF アプリケーションでは、ドキュメントを OPC レベルで処理することもできます。これにより、XPS ドキュメント、2007 Office system ドキュメント、および他のドキュメントに一般的なアクセスを行うことができます。マイクロソフトの Windows Workflow Foundation で構築されたアプリケーションも、これらの API により、XPS ドキュメントを使用するワークフローを作成できます。

WPF は、アプリケーションで固定書式ドキュメントの表示や処理を可能にすることで、最新のユーザー インターフェイスにおける固定ドキュメント処理の方法を統一します。また、Windows Vista は、ドキュントの印刷に同じフォーマットを使用することで、画面で表示されるドキュメントが、印刷でより忠実に再現されるようにします。この種のドキュメントの使用はユーザー インターフェイス テクノロジにそれほど求められている分野ではないにしろ、XPS を幅広く活用できるという事実は、WPF などのテクノロジが網羅する範囲の広さを物語っています。

Windows Presentation Foundation のツール

1 つの特長として、WPF には開発者向けの機能が数多く用意されています。テクノロジがどれほど優れていても、良いツールがないとその効果は発揮できません。WPF では、開発者向けのツールと、デザイナ向けのツールがそれぞれ用意されています。ここでは、それらのツールについて概観します。

開発者向け: Visual Studio

Visual Studio は、マイクロソフトの代表的なソフトウェア開発ツールです。WPF の初期リリース時に、マイクロソフトは WPF アプリケーションを作成するための Visual Studio 2005 拡張機能を提供する予定です。Visual Studio の次期リリース (コードネーム "Orcas") では、Visual Designer for WPF (専用のコードネーム "Cider" を持つ) を含むさらに多彩な機能が追加される予定です。このビジュアル ツールを使用し、開発者は WPF インターフェイスをグラフィカルに作成し、インターフェイスを記述する XAML を自動的に生成できます。Orcas の正式なリリース日は発表されていません。

デザイナ向け: Expression Interactive Designer

前述のように、WPF の最重要目標は、ユーザー インターフェイス作成という世界に、デザイナたちを第一級市民として迎えることにあります。XAML はこれを可能にしますが、それはデザイナが新しい世界で活躍するためのツールがあればこそです。これを実現するため、マイクロソフトは Expression Interactive Designer を作成しました。

次のスクリーン ショットが示すように、Expression Interactive Designer には、デザイナが使い慣れた環境で作業できるように、従来のデザイン ツールに似た機能がいくつか用意されています。とはいえ、Expression Interactive Designer は WPF アプリケーション インターフェイスの作成に特化しています (実際、このツールのインターフェイス自体も WPF を使用して構築されています)。たとえば、次の画面右上にある WPF コントロールのリストや、下部にあるグラフィカル タイムラインに注目してください。これらの要素は、前述の各 WPF 機能に対応し、インターフェイス デザイナはそれらすべてを利用できます。変形、効果などと同様に、アニメーションをグラフィックで作成することもできます。デザイナが作成したデザインは、ツールによって XAML ファイルに記述され、Visual Studio にインポートすることができます。

introducingwpf8.gif

図 9: Expression Interactive Designer により、デザイナは WPF インターフェイス ( 図 8) を作成できる

Expression Interactive Designer は、マイクロソフトの Expression ファミリを構成する 3 製品の 1 つです。他の 2 つは、標準ベース Web インターフェイス作成ツールの Expression Web Designer と、ベクタ/ビットマップ画像作成ツールの Expression Graphic Designer です。これら 3 製品のうち、Expression Interactive Designer だけが WPF アプリケーション ユーザー インターフェイスの作成に特化しています。確かに、デザイナはユーザー インターフェイスのある部分を作成するために他のツールを使用するかもしれません。たとえば、インターフェイス のGIF 画像の作成に Expression Graphic Designer を使用する場合などがそうです。しかし、それらのツールは WPF 専用ではありません。日程は明らかにされていませんが、すべての Expression ツールは WPF のリリース後に出荷される予定です。

Windows Presentation Foundation と他のマイクロソフト テクノロジ

ほとんどのマイクロソフト新テクノロジと同様に、WPF は Windows の他のテクノロジにも影響を及ぼします。それらの影響を考慮する前に理解しておくべき点として、システムに WPF をインストールすることで、Windows フォーム、MFC、その他の既存テクノロジを使用するソフトウェアの動作が妨げられることはありません。確かに、.NET Framework 3.0 をサポートするシステム向けの新しいアプリケーションでは、ほとんどのインターフェイスが WPF で構築されるでしょう。しかし、既存テクノロジを使用するアプリケーションは引き続き正常に機能します。

Windows Presentation Foundation と Windows フォーム

.NET Framework の初期リリースから、多くのアプリケーションが Windows フォームで作成されてきました。WPF の登場後も、引き続き一部のアプリケーションでは Windows フォームが使用されるでしょう。たとえば、旧バージョンの Windows など、WPF を使用できないシステムで実行されるアプリケーションでは、インターフェイスに Windows フォームが使用されるでしょう。新しいアプリケーションを作成する場合でも、Windows フォームで使用できる多彩なコントロール セットを活用したい、などの理由から、WPF ではなく Windows フォームが使用されるかもしれません。

実際、WPF でアプリケーションを構築する場合でも、Windows フォームのある面が役立ちます。たとえば、現在の Windows フォームには、WPF よりも多くのコントロール セットが提供されています。一例として、WPF には、.NET Framework バージョン 2.0 で導入された DataGridView コントロールに相当するものがない一方で、Windows フォームにはサード パーティによってさまざまな用途のコントロールが提供されています。したがって、WPF アプリケーションでこれらの既存のコントロールを使用できるなら便利でしょう。逆に WPF には、3D グラフィックスやアニメーションなど、Windows フォームにはない機能があります。したがって、既存の Windows フォーム アプリケーションに、WPF 機能の一部を組み込めるなら、これもまた便利です。

実に、これら両方のことが可能になります。つまり、WPF アプリケーションが Windows フォーム コントロールをホストし、Windows フォーム アプリケーションが WPF コントロールをホストすることができるのです。ユーザーは、同じアプリケーション内で違和感なく WPF ダイアログおよび Windows フォーム ダイアログと対話できます。

WPF アプリケーションは、 Windows フォーム コントロールをホストするために、WPF の WindowsFormsHost コントロールを使用します。その名が示すように、このコントロールは Windows フォーム コントロールをホストし、WPF アプリケーション内でそのコントロールを使用できるようにします。さらに、ActiveX コントロールをホストし、WPF アプリケーションが、旧テクノロジで作成された豊富な既存ライブラリにアクセスできるようにします。同様に、Windows フォーム アプリケーションは、WPF コントロール、パネル、および他の要素をホストするために、Windows フォーム コントロールの ElementHost を使用します。さらに、一方のテクノロジに対応するツールで、他方のテクノロジで記述されたソフトウェアを扱うこともできます。したがって、WPF の Visual Designer を使用して Windows フォーム コントロールを配置することも、Windows フォーム デザイン ソフトウェアを使用して WPF コントロールを配置することもできます。

とはいえ、WPF と Windows フォームの併用には、いくつかの制限があります。たとえば、WPF コントロールを Windows フォームの上に重ねることはできません。Windows フォーム コントロールは、常に一番上に表示されます。また、WPF の透明効果、および WPF の変形効果は、Windows フォーム コントロールで正常に機能しません。さらに、WindowsFormsHost および ElementHost コントロールには完全信頼が必要なため、これらのコントロールを使用する WPF アプリケーションは XBAP として実行できません。しかし、ほとんどの Windows アプリケーションは、WPF と Windows フォームの両方を使用して、ユーザー インターフェイスを作成できます。

Windows Presentation Foundation と Win32/MFC

2002 年に .NET Framework がリリースされる前、Windows 開発者は Win32 API へのダイレクト呼び出しか、それら API の C++ ラッパーを提供する MFC のいずれかを使用して、ユーザー インターフェイスを構築していました。したがって、この方法で作成されたインターフェイスには、現在でも大量のコードが含まれています。WPF では、このコードはどうなるのでしょうか?

答えは、Windows フォームの場合と似たものになります。すなわち、WPF コントロールを既存の Win32/MFC コードにホストし、既存の Win32/MFC コントロールを WPF にホストすることができるというものです (実際、WPF と Windows フォーム間の相互運用性は、Win32/MFC 相互運用サービス上に構築されています)。WPF には、WPF での Win32/MFC コントロールの使用を可能にする HwndHost クラスと、Win32/MFC アプリケーションでの WPF コントロールの使用を可能にする HwndSource クラスが用意されています。各クラスは、必要に応じて、2 つのテクノロジ間をマップします。たとえば、HwndHost は、Win32/MFC コントロールの参照に使用される hWnd を WPF コントロールのように見せかけます。HwndSource はその逆を行い、WPF コントロールを hWnd のように見せかけます。

Windows フォームの場合と同様に、これらのテクノロジの併用にはいくつかの制限があります。実際、Windows フォームとの相互運用性は HwndHost と HwndSource に基づいているため、前述の Windows フォーム コントロールに関連する制限すべてがここでも適用されます。したがって、フォームを重ねたり、透明効果を使用したりすることはできません。さらに、Windows フォームの場合とは異なり、WPF と Win32/MFC コードが混在するアプリケーションでは、WPF マネージ コード環境と Win32 アンマネージ環境との相互運用性という、別の問題も生じます。この相互運用性の問題と他の理由によって、Win32/MFC コードを使用する WPF アプリケーションは、XBAP として実行することはできません。とはいえ重要な点は、既に述べたとおり、Windows アプリケーションで WPF と Win32/MFC を併用できるということです。WPF を使用するために、アプリケーションの既存のユーザー インターフェイス コードすべてをあきらめる必要はありません。

Windows Presentation Foundation と Direct3D

マイクロソフト API の DirectX ファミリを構成する Direct3D は、3D グラフィックスを作成する Windows 開発者にとって主要な API です。WPF の登場で、Direct3D が時代遅れになることはありません。実際、前述のように WPF はレンダリングを行うために Direct3D に完全に依存しています。しかし、WPF でも 3D グラフィックスを作成できるので、3D を扱う開発者は、どちらのテクノロジを選択するべきかという問題に直面します。

この決定を行うのはさほど難しくありません。ゲームや、3D 中心のテクニカル アプリケーション (たとえば、高度な科学表現) など、高度な 3D 開発には依然として Direct3D が最適です。少なくとも最初のリリースの WPF は、このようなタイプのソフトウェア プラットフォームとして機能するよう設計されてはいません。

とはいえ、WPF によって、専門知識を持たないさらに多くの開発者は 3D グラフィックスを扱えるようになります。また、WPF によって、XBAP の Web 上で 3D グラフィックスを使用することができ、3D グラフィックスを 2D グラフィックス、ドキュメント、アプリケーションのユーザー インターフェイスの他の要素とシームレスに統合できます。加えて、前述の HwndHost クラスを使用し、WPF アプリケーションで Direct3D をホストすることもできます。このように、WPF と Direct3D はそれぞれが明確な役割を持っており、その両方が Windows プラットフォームの一部としてこの先も有用な機能です。

Windows Presentation Foundation と AJAX/"Atlas"

AJAX を使用すると、開発者はユーザーの要求に応答する以上のことが可能なブラウザ クライアントを作成できます。AJAX により、ユーザーは各リクエストでページの更新 (Web サーバーとのラウンド トリップ) を行うことなく、アプリケーションと対話できます。AJAX がこの機能を実現するには、ブラウザで XMLHttpRequest オブジェクトがサポートされている必要があります。このアイデアは、1990 年代後半の Internet Explorer 5.0 で最初に登場しました。その後の最初の 5 年間に、さまざまなブラウザで XMLHttpRequest のサポートが進み、AJAX ブームが到来しました。

とはいえ、AJAX クライアントの作成は簡単ではありません。この作成プロセスをサポートするため、マイクロソフトはコードネーム "Atlas" というテクノロジセットを開発しました。(訳注: ASP.NET "Atlas" は ASP.NET AJAX と名前が変わっています) Atlas は、AJAX アプリケーションを作成するためのライブラリ、コントロール、その他の機能をまとめたものです。Atlas には、さまざまなブラウザ (Internet Explorer に限られません) で機能するクライアント スクリプト ライブラリと、ASP.NET に対するサーバー側の拡張機能が含まれています。その目的は、AJAX クライアントを使用する Web アプリケーションをより簡単に作成できるようにすることです。

AJAX がブラウザでますますサポートされていることは、開発者にとって非常にうれしいことです。しかし、AJAX でスムーズな対話が可能なインターフェイスを作成できるとはいえ、それによって多様なコンテンツ タイプがサポートされるわけではありません。グラフィックス、ビデオ、アニメーション、その他の最新の対話スタイルは、AJAX だけでサポートできるものではありません。WPF をサポートするクライアントでの場合、これらを必要とするアプリケーションは XBAP として記述されるでしょう。

Windows Presentation Foundation と "WPF/E"

XBAP を使用することで、Web アプリケーションはユーザーに対して WPF 機能の大部分を提供できます。ただし、XBAP を使用するにはクライアント マシンに WPF がインストールされていなければならず、この点が XBAP の適応性のネックになります。Web アプリケーションで最新のインターフェイスを使用する必要があり、かつ WPF をサポートしないMacintosh や他のシステムからもアクセスできるようにするにはどうすればよいでしょうか?

新たに登場するコードネーム "WPF/E" は、この問題を解決するために開発されています。"Everywhere (どこでも)" の "E" を冠する WPF/Eは、Macintosh や小型デバイスなどの幅広いクライアント プラットフォーム上で、Internet Explorer、Firefox、Netscape などの多様な Web ブラウザに対して WPF 機能のサブセットを提供します。このサブセットには、2D グラフィックス、画像、ビデオ、アニメーション、テキストが含まれます。ただし、3D グラフィックス、ドキュメント、およびハードウェア アクセラレータのサポートなど、XBAP で可能な一部の機能は WPF/E に含まれません。

WPF/E アプリケーションの作成には、JavaScript を使用できます。また、WPF/E には .NET Framework のクロスプラットフォーム サブセットが含まれており、C# および Visual Basic での開発が可能です。WPF/E は .NET Framework 3.0 に含まれていないため、2006 年内のリリースは予定されていません。今後このテクノロジがリリースされれば、Web アプリケーションの作成者は、さまざまなプラットフォーム上でクライアントを構築するための幅広い機能を備えたオプションを手にすることになるでしょう。

まとめ

ほとんどのアプリケーションで、ユーザー インターフェイスは非常に大きなウェイトを占めます。したがって、それらのインターフェイスをできるだけ効果的なものにするなら、インターフェイスを使うユーザーや組織は大きなメリットを手にすることができます。WPF の最重要目標は、これらのメリットを提供できるように開発者を支援することです。したがって、WPF のリリースは Windows アプリケーションの開発者とユーザー双方にとって朗報です。

WPF は、最新のユーザー インターフェイス開発の統合プラットフォームを提供し、デザイナがユーザー インターフェイスの作成過程に積極的に参加することを可能にし、またスタンドアロン アプリケーションおよびブラウザ アプリケーションに共通のプログラミング モデルを提供することで、Windows ユーザー エクスペリエンスを大きく改善することを目指します。WPF に取って代わられるテクノロジには、Windows ユーザー インターフェイスの基盤として 20 年の歴史を持つものがあります。次は、WPF が今後の 20 年間の基盤としての役割を果たす番です。

著者紹介

 

David Chappell 氏は、カリフォルニア州サンフランシスコにある Chappell & Associates (www.davidchappell.com) (英語) の社長を務めています。講演、著書、およびコンサルティングを通じて、世界中の IT プロフェッショナルがエンタープライズ ソフトウェアを理解し、使用すること、および適切な判断を下すことを支援しています。