| ||
| ||
| ||
| ||
| ||
| ||
| ||
|
2005～2006年に出荷予定の次期Windows「Longhorn（開発コード名）」。2003年10月に米国Los Angelesで開催した開発者向け会議「Professional Developers Conferece 2003」で，そのプレビュー版を参加者に配布した。ユーザー・インタフェースは暫定的なものだが，API（アプリケーション・プログラム・インタフェース）の基本構成は製品版と同じだ。このAPIから，Longhornの実像が垣間見えてくる。
Win32を捨てWinFXへ
APIの点から見ると，一番大きいのはWin32からWinFX（開発コード名）への転換である。WinFXは.NET Frameworkの機能拡張版と考えればよい。Windows XP/2000などで利用できる.NET Frameworkは，Windowsの機能をフルに利用できなかった。Win32よりもカバー範囲が狭かったのである。具体的にはDirectX関連の処理が記述できなかった。
だがWin32は，その名前の通り32ビットのx86系CPUに対応したWindows用のAPIである。ItaniumやAMD64といった，64ビット・アーキテクチャ向けのWindows APIとは，厳密には互換性がない。両方のアーキテクチャに対応したアプリケーションを開発するには，.NET Frameworkのような仮想的な実行環境が必要となる。将来的にインテル系のCPUだけでなく，さまざまなアーキテクチャに対応していくには，ネイティブ・コードで直接アプリケーションが動くのは得策ではないのだ。
WinFXも.NET Frameworkと同様，マネージコード（Managed Code）と呼ばれる仮想環境で動作する。.NET Frameworkと比較すると，WinFXで追加された大きな構成要素は三つある。画面描画機構「Avalon」，データベースを使ったファイル管理システム「WinFS」，およびプログラム間通信を司る「Indigo」である。.NET Frameworkで提供してきたWindows Formsや，ASP .NET，ADO .NETといったAPI群もWinFXに含まれることになる。
|
Avalon |
プログラマにとって一番大きな変化と言えるのが，Avalonの導入だろう。Avalonの特徴は画面設計のプログラム・コードからの独立である。これはプログラミング作業のプロセスを変えてしまう。具体的には，画面構成を「XAML（eXtensible Application Markup Language）」というマークアップ言語で記述する。
XAMLによる記述は，ASP .NETにおけるWeb画面の設計に似ている。ASP .NETではWebの画面はHTMLをベースに，テキスト・ボックスやボタンなどブラウザで表示可能なコンポーネントを配置する。適切にIDさえ割り当てておけば，プログラミングを知らないデザイナが後から編集することも可能だ。デザインとコードの分離を実現できるモデルである。
同様にXAMLでも，配置したいコンポーネントをタグで指定する。個々のコンポーネントに設定するプロパティもタグのなかに記述できる（リスト1[拡大表示]）。XAMLはXMLなので，デフォルトのエンコーディングはUTF-8である。したがって外部コード形式がシフトJISであるLonghornでは，先頭行にエンコーディングを指定しないと日本語が表示されない。XAMLで記述したファイルは，ダブルクリックするとレイアウトした結果を表示できる（画面1[拡大表示]）。
レイアウトの考えはJava風
もう少し詳細にレイアウトしてみよう（画面2[拡大表示]）。XAMLにおいては，コントロールは「Panel」の上に配置される。Panelは標準で6種類あり，それぞれレイアウトの方針が異なる。このあたり，Javaの標準UIコンポーネントであるJFC/Swingにおける，レイアウト・マネジャと発想が似ている。
ここではメニュー項目を表示させるので，DockPanelを使っている。DockPanelはレイアウトする項目を上（top），下（bottom），左（left），右（right），中央（center）にそれぞれ固定（dock）させることができるパネルである。メニューは上部に固定したいのでDockPanelを使うことになる。
ここではメニュー以外の項目は適当に並べているだけなので，FlowPanelを使って配置している。FlowPanelは並べた項目の横幅に応じて適宜改行してレイアウトするパネルである。このほかのパネルとしては，グラフィックス要素を任意の指定位置に配置するためのCanvasパネル，複数行の文章を配置するためのTextPanel，表のような縦横に並んだ配置をするGridPanel，ウインドウの大きさなどによらず固定的に配置するFixedPanelがある。
メニューはMenuコントロールに記述する（リスト2[拡大表示]）。MenuItemコントロールを複数個まとめたものがMenuである。MenuItemはサブメニューを作れる。このあたりは表記はともかく，通常のメニュー設定と同じなので迷うことはない。ListBoxやButton，RadioButton，などのコントロールも同様である。
共通のレイアウトをリソースに定義
複数の要素に共通して適用したいレイアウトは「リソース」として定義できる（リスト3[拡大表示]）。これを有効活用すれば，デザインの一貫性を保ちやすくなる。
リソースはパネル単位で設定する。基本的には複数のプロパティを一気に設定できるよう，「Style」を定義するのが普通だろう。ただ「SolidColorBrush」のように，カスタムカラーのような形式の定義も可能である。名前を付けたリソースは，｛｝で囲って指定することになる。
プログラムとの連携
見てきたようにレイアウトをXAMLで定義できるようになったわけだが，このままではプログラムから利用できない。ここでは，テキスト・ボックスに入力した文字列を，リストボックスに追加していくプログラムを作成してみる（画面3[拡大表示]）。
それぞれのコンポーネントを操作するためには，まず個々のコンポーネントを識別できなければならない。このため，それぞれのコンポーネントは「ID」というプロパティを備えている。識別するための名前をIDに割り当てる。
次に，イベントが発生したときにその処理をする手続きの名前を指定する（リスト4[拡大表示]）。また，全体のプロパティにある「CodeBehind」に，処理を担当するC＃などのソースファイルの名前を指定しておく。これでXAML側の準備が終わる。
ソースファイルでは，XAMLで定義した名前をそのまま使う（リスト5[拡大表示]）。イベント・ハンドラ名や，コンポーネントの名前が一致していないと，うまく動作しない。
ここでASP .NETの経験がある読者は，プログラミング・モデルがまったく同じであることに気づかれたかもしれない。ASP .NETのHTMLの代わりにXAMLを使っているのだと思って間違いない。多少その表記方法が違うだけであり，ASP .NETに慣れていればすぐにAvalonのプログラミングの基本はマスターできるだろう。
Avalonのプログラミング・モデルは，ASP .NETにJFC/Swing的なレイアウトの考えを取り入れたものだといえる。ただJavaのプログラムがなかなか望み通りにレイアウトできないのと同じように，今のままだとXAMLを使ってレイアウトするのは結構面倒である。FlowPanelを使うと，挙動の予想もつきにくい。その意味では，Avalonを使ったGUI設計ツールが完成する，次の次にくるVisual Studio .NET「Orcas（開発コード名）」までその真価はつかめない。
