Lesson 8 ユーザー・インタフェイス再び
7. 法律用語
いくつか細かい所が残っています。例えば使用許諾契約書のページです。
ラジオ・ボタン・グループについては、ソースの後の方で独立した記述をします。 リンクは Property 属性によって確立されます。
今回、次に表示するダイアログの選び方は、ほんの少し手が込んでいます。
インストールによっては、ユーザー名、会社名、および、登録キーの入力をユーザーに求めたくないことがあります。
それに応じて UI を修正する (ページの進行の中で単純にそのページを呼ばないようにする) ことも可能ですが、
ここではもっとエレガントな解法を用います。
ShowUserRegistrationDlg というプロパティをどこかで定義しておきます。
このプロパティを 1
に設定すれば、ユーザー登録ページが表示されます。
0
に設定すれば、ユーザー登録ページはスキップされます。
このことは、それぞれの場合に対応する二つの NewDialog イベントを用意することを意味します。
SpawnDialog イベントと SpawnWaitDialog イベントは前のページを置き換えずに、新しい子ダイアログ・ボックスを開始します。
前者はユーザーのアクションによって終了されるのを待ちますが、後者は条件式が偽である間だけ表示されます。
私たちの場合では、インストーラが必要なディスク容量を計算している間だけ表示される「お待ち下さい」ダイアログが後者の例です。
サンプルのような小さなインストーラ・パッケージでは、計算には全く時間がかかりませんので、
このダイアログが動いているのを見る機会はまず有りません。
それでも、念のために、ダイアログを用意しておきましょう。
CostingComplete は、必要なディスク容量の計算が完了した時に 1
に設定される定義済みのプロパティです。
そして、最後に、おなじみの嫌がらせです。 「次へ」ボタンはユーザーが使用許諾契約への同意を示すまでは無効化された状態に留まります。 私たちは既に Condition タグを上位のレベルで使ったり (インストールのプロセス全体を走らせるべきかどうかを決める起動条件)、 Feature タグの中で使ったりしました (さまざまな機能のインストールを条件によって無効化する)。 ここで第三の使い方、Control タグの中での使い方を説明します。 Action 属性を使うと、Condition タグの内側の条件が真と評価される場合に、コントロールを disable, enable, hide または show する (あるいは default の状態に戻す) ことが出来ます。
小さな事ですが、注意深い読者は気付いているでしょう。
条件式のいくつかに対して、私たちは格好悪い <![CDATA[...]]>
ラッパーを使いました。
コンパイラのパーサーが XML タグの間に出現する < や > のような特殊な文字によって混乱することが無いようにするためです。
最も安全な方法は条件式を全てラップすることでしょう (WiX のデコンパイラ、Dark はまさしくそうします)。
けれども — 少なくとも私の考えでは — それではソースがあまりにも読みにくくなります。
それが嫌なら、本当に必要な所だけにラッパーを使うために、どの式が曖昧でどの式がそうでないかについて自分で配慮しなければなりません
(何か理解できない所があれば、コンパイラがエラー・メッセージを出してくれます)。
どちらを選ぶかは、あなた次第です …
次の部分は既によく知っているところです。
次に使用許諾契約書のテキストが来ます。 スクロール可能なコンテンツを持った凹んだテキストのコントロールを開きます。 実際のテキストは内部の Text タグに入ります。 ここでは RTF 形式のテキスト・ファイルを指定することが出来ます。 ですから、使用許諾契約書をワード・プロセッサで書いて RTF としてエクスポートするというのが、最も良い考えです (この目的のためには、ワードパッドがおそらく最善のワード・プロセッサです。 高機能なものを使うと、RTF ファイルがひどく冗長なものになります。 高機能なワード・プロセッサを使うとしても、最終版をワードパッドで保存し直すことを考慮して下さい)。
契約書のテキストは、ソース・ファイルのこの箇所に直接に書き込むことも出来ます。 しかし、既に述べた方法の方が、はるかに保守が容易であると思われます。
残されている部分は本当に簡単で、詳細な説明には値しません。 あっちやこっちに、タイトル行と水平線を付けて、ダイアログの残りの部分を作ります。
返済すべき借りがまだ有ります。 ダイアログの最初のコントロールで、ラジオ・ボタン・グループの記述に言及しましたが、それが保留されたまま残っています。 ですので、以下にそれを示します。 Text 属性の中のプロパティ置換に注目して下さい。 このようにすると、テキストのフォント、サイズ、および色を指定する事が出来ます。
しかしこれらのフォントの定義はどこにあるのか、と質問されますか? オーケー、次に示します。 これは、さまざまなテキスト・スタイルを集中管理的に定義する方法で、 ユーザー・インタフェイスのどこからでもこれらのテキスト・スタイルを簡単に参照できます。 色については、Red, Green および Blue の属性を使うことが出来ます (それぞれ 0 から 255 の間の値を指定します)。 追加の装飾として、Bold, Italic, Underline および Strike を指定する事が出来ます。
ソース・ファイルの最後には、プロパティの定義が来ます — 基本的には、私たちが使う変数とその初期値です。 プロパティの中には、インタフェイス要素のテキストの略記として使われているものもあります。 地域化するときは、これらも修正する必要があります。 アンパサンドと角括弧の文字に注意して下さい。 値全体を CDATA ラッパーで包むか、または、こういう扱いにくい文字に XML 実体参照を使うかしなければなりません (ButtonText_Next と ButtonText_Back を比較して下さい)。
インストーラ・パッケージには、製品と一緒にインストールしたくないけれど、ユーザー・インタフェイスには必要になるファイルが付いています。
つまり、ビットマップとアイコンです。これらについて、ソース・ファイルの末尾で記述します。
これまで、ビットマップとアイコンは Id 識別子を使って参照してきましたが、ここで実際のファイル名を定義します。
これらのファイルは、独立したキャビネットを要求した場合でも、.cab
ファイルではなく .msi
ファイルに格納されます。
ビットマップやアイコンを変更したいときは、Binary ディレクトリの中だけで変更して下さい。 表紙のビットマップ (ここでは Dialog.bmp という名前です) は、503 × 314 ピクセルの BMP ファイルで、 上部のバナー・ビットマップは 500 × 63 ピクセルです。 しかし、ユーザーのシステム・フォントと表示解像度の設定によってインタフェイス全体の拡大縮小が要求される場合には、 Windows Installer がこれらのビットマップを拡大または縮小する可能性があることに注意して下さい。 拡大縮小に伴う醜くて不自然な結果を避けるために、適切なビットマップを使わなければなりません。 均一に見えることを想定した画像を横切る細線のストライプ模様は避けて下さい。 ビットマップにテキストを組み入れてはいけません (ロゴの文字は OK ですが、読んで貰うことを意図した小さなテキストは駄目です)。 そして、何よりも、ディザ処理した領域とチェッカー模様の背景は禁物です。 これらは拡大縮小されるとひどく不自然に見えます。 画像エディタを使って、いろんな倍率で拡大縮小の実験をしてみれば、何を言っているのか分るでしょう。 ただし、バイキュービック・サンプリングなどの洗練されたアルゴリズムは必ず無効にしてください。 Windows は単純な拡大と縮小しか使用しません。
訳註:500 × 63 ピクセル、および、503 × 314 ピクセルというビットマップのサイズは、 WiX 2 時代のライブラリが内蔵していたビットマップのサイズに依拠するものです。 現在の WiX 3 のライブラリが内蔵しているビットマップのピクセル・サイズは、それぞれ、493 × 58 ピクセル、493 × 312 ピクセルです。
ただし、これらのビットマップのサイズは、本文の記述からも分るように、絶対にそうでなければならない、というものではありません。 それぞれの時代において、その時の標準的な Windows のシステム・フォントと表示解像度のもとでは、 そのようなピクセル・サイズのビットマップなら拡大縮小されることなく等倍で表示される、ということです。