タグで、インストール先として指定したディレクトリです。することによって、私たちが元来意図していたインストール先をユーザーが変更出来るようにしている訳です。この属性を使用しないようにすれば、ユーザーは前と同じようにいろいろな機能を有効にしたり無効にしたりする事は出来ますが、インストール先ディレクトリは変更することが出来なくなります。カスタムの設定カスタムのツリービューの各項目には、コンテキスト・メニューが結び付けられていて、ユーザーはどの機能をどのようにインストールするかを決めることが出来ます。メニュー項目の既定値は以下の通りです。この機能はローカルのハード・ドライブにインストールされます。この機能とすべてのサブ機能はローカルのハード・ドライブにインストールされます。この機能はネットワークから実行するようにインストールされます。*この機能とすべてのサブ機能はネットワークから実行するようにインストールされます。*この機能は必要になったときにインストールされます。この機能はインストールされません。いろんな属性を使うと、これらの項目のいくつかを削除したり修正したりして、その機能にとって意味のあるものだけを残すことが出来ます。基本的には、五つの選択肢が有り得ます。要求に応じてインストールする(機能はユーザーが初めて使おうとした時にインストールされます。インストールしない、の五つです。コンテキスト・メニューから削除されます。ユーザーはこの機能を必要に応じてインストールすることが出来ません。コンテキスト・メニューに出現します。ユーザーはこの機能を必要に応じてインストールすることが出来ます。コンテキスト・メニューに出現して、ユーザーが必要に応じてこの機能をインストールすることが出来るようになります。コンテキスト・メニューに出現します。コンテキスト・メニューに出現します。)は、親の機能の設定に従います。コンテキスト・メニューに出現します。ユーザーはこの機能をインストールするかしないかを決めることが出来ます。コンテキスト・メニューから削除されます。この機能は常に必要とされ、ユーザーはこの機能のインストールを拒否することが出来ません。機能の中にファイルが含まれていないと、上記で概観した属性を使って削除しようとしても、この項目がコンテキスト・メニューに出現してしまいます。いう場合は、その機能に(中にファイルを含まない)空っぽのコンポーネントを追加して下さい。魔法ここからが本当のマジックです。どの程度まで高機能なユーザー・インタフェイスを求めるかに応じて、五つの異なるウィザードを提供してくれます。「ようこそ」のページ、使用許諾契約、セットアップ・タイプ(標準、カスタム、完全)、機能のカスタマイズ、インストール先ディレクトリの参照とディスク容量の計算など、完全なインタフェイスを提供します。メンテナンス・モード用のダイアログも含まれています。製品の機能の中に既定ではインストールすべきでないものがある場合(言い換えると、標準インストールと完全インストールの間に、重要で意味のある違いがある場合)は、このタイプを使用すべきです。フル・セットと同じですが、ユーザーはセットアップ・タイプを選択することが出来ません。セットアップ・タイプは常にカスタムであるという前提に立って、ユーザーが使用許諾契約に同意した後は、直接に、機能のカスタマイズのダイアログに進みます。ユーザーがインストール先ディレクトリを選ぶことが出来ますが、通例の機能をカスタマイズするページは提供されません。ディレクトリの選択が完了すると、自動的にインストールが始まります。非常に簡単なユーザー・インタフェイスを特徴としていて、「ようこそ」のページと使用許諾契約のページを一緒にした単一のダイアログがあるだけです。このダイアログの後は、ユーザーに何もカスタマイズを許さず、インストールが自動的に進行します。アプリケーションがインストールすべきオプション機能を何も持っていない場合に使って下さい。良く似ていますが、ユーザーがそうしたいと望めば、機能やフォルダを選ぶことも出来ます。インタフェイス・ライブラリをプロジェクトに含めることだけです。/>最初の参照によって適切なユーザー・インタフェイス・ライブラリが読み込まれます。このライブラリは、言語ファイルにあるローカライズされたエラーとアクションのテキスト(英語の場合は、修正されたテキスト)を自動的に使う訳ではありません。内部にある組み込みのメッセージを使うようになります。ダイアログ・セットを使う場合は、ソースのどこかで、下記のように、追加のプロパティを提供しなければなりません。/>そして、最後に、これまでのサンプルと全く同じように、ソースの記述を終了します。</Product></Wix>ユーザー・インタフェイスの変種のすべては、共通のコンパイル済みライブラリに入っています。私たちは、既に述べたようにコマンド・ライン・スイッチを使って、この拡張ライブラリに対してリンクするだけで良いのです。統合開発環境の中で作業をしている場合は、同じ効果を得るために、このライブラリに対する参照を追加する必要があります。SampleWixUI.wixobjユーザー・インタフェイスの外観のいくつかは、代替のファイルを指定するだけでカスタマイズすることが出来ます。既定のファイルはツールセットの中にありますが、代替のビットマップ、アイコン、ライセンス文書を自分で作ることが可能です。全部でなく、特定のファイルだけを置き換えることも出来ます。ファイルのパスは変数に保持されていますので、コマンド・ラインで指定することも、直接ソースに書くことも出来ます。/>これらの意味と詳細は以下の通りです。このビットマップは、最初のページを除く全てのページの上部に表示されます。このビットマップは、インストーラの最初のページに表示されます。ワードパッドのような単純なエディタを使って作成して下さい。してもワードのような必要以上に複雑なアプリケーションを使いたい場合は、せめて最終版はワードパッドで保存し直すことを検討して下さい。ファイルがシンプルで小さくなります。ピクセルと記述されています。時代のライブラリが内蔵していたビットマップのサイズに基づくものです。ライブラリが内蔵しているビットマップのピクセル・サイズを記しました。これらのビットマップのサイズは、絶対にそうでなければならない、というものではありません。末尾にあるビットマップについての記述および訳註を参照してください。両方のタグで、言語とコードページの両方を正しく指定するように気をつけて下さい。言語の設定が正しくないと、インストーラの基本言語とは異なる、予期しない言語のエラー・メッセージがポップ・アップすることがあります。コードページが正しくないと、アクセント記号付き文字や非欧文文字がまったく表示されないことがあります。いくつかの言語については、リリース・パッケージの地域化ファイルの代りとして、もっと洗練された自然な言い回しの理解しやすい翻訳を同時に提供しています。インストールで使っている通常の表現とはいくつかの点で異なっていますが、私たちの個人的な見解では、リリース版よりも単純で分りやすい言葉を使っています。それらを調べてみて、インストール・パッケージにどちらを使うかを決めるのは、完全にあなたの自由です。拡張ライブラリに入っています。これらを使う場合は、カルチャ名を指定するだけ済みます。統合環境を使っている場合は、プロジェクトのプロパティ・ダイアログに「カルチャ」欄がありますので、そこでカルチャ名を指定できます。カンマで区切って複数のカルチャ識別子を指定すると、その全部について、個別のインストーラが作成されます。SampleWixUI.wixobj完了状態の言語(リリースへの承認待ちののもの)や、代替の言語ファイル(上記のテーブルからダウンロードしたものや、あなた自身が作ったもの)は、コマンド・ラインで直接に指定することが出来ます。ファイルを含めるだけで、適切なインストーラが自動的に作成されます。訳註:残念ながら、リリース版の日本語地域化ファイルの品質はあまり良くありません。不明瞭な表現や不自然な言い回しが多く、中には明らかに誤訳と思われるものあります。代替版(WixUI_Alt_ja-jp.zip)を参考に供しますので、ご自由にお使い下さい。さんのご協力を頂きました。インタフェイス・ライブラリは、通常のセットアップ・シナリオのほとんどを扱うことが出来ますが、ときには修正や追加が必要になることもあります。ダウンロードしなければなりません。言うのは、いくつかのソース・ファイルを覗き見する必要があるからです。ライブラリを修正して、ユーザーに登録情報(名前、組織、シリアル番号)を入力してもらうダイアログを追加します。ダイアログと「セットアップ・タイプ」ダイアログの間に出現します。いう新しいファイルを提供しなければなりません。既存のダイアログから始めて、それを修正しても構いませんし、一から自分で書いても構いません。さまざまなインタフェイス要素の使い方を説明しますが、ここでは、いくつかの注意点を述べるにとどめます。xmlns='http://schemas.microsoft.com/wix/2006/wi'>新しいダイアログは独立した断片(fragment)として記述しなければなりません。/>このダイアログが、元の一連のダイアログの中に挿入されます。このダイアログに先行するダイアログと後続するダイアログを指定しなければなりません。するのは「セットアップ・タイプ」です。見ると、これらのダイアログの実際の識別子を知ることが出来ます。従って、この新しいダイアログから、これら前後のダイアログを参照するように、以下のように記述します。<Text>あなたのユーザー情報を入力して下さい。</Fragment></Wix>新しいダイアログを元のユーザー・インタフェイスに組み込むことはかなり簡単です。タグで私たち自身のインタフェイスを作成します。呼び出してから、修正部分を追加します。ダイアログを参照します。次に、残っている二つのリンクを定義しなければなりません。ダイアログは「セットアップ・タイプ」ダイアログを後続するものとして指し示していました。今や新しいダイアログが両者の間に挿入されている訳ですから、元のダイアログの「次へ」および「戻る」のリンクをそれに合わせて修正しなければなりません。属性を修正して新しいダイアログを指し示すようにする、という方法です。</UI>メインのソース・ファイルは、私たちが参照したプロパティを定義しなければなりません。マスク・エディット・コントロールは、いろんな文字を使って、どんな内容がどのようにコントロールに表示されるか、どんな種類の入力をコントロールが受け入れるか、そして、データを受け取るプロパティに割り当てられる最終的なデータがどのような書式で整形されるか、という事を決定します。###>@@@@@]]></Property>これで全てです。これで、修正されたインストーラを下記のコマンドによってビルドすることが出来ます。追加したら、同じように地域化(ローカライズ)もしたいですね。そのためにかかる余分の手間は、それほど大きくはありません。メインのソース・ファイルは同じままです。中の新しいダイアログだけです。固定されたテキストの代りに、地域化できる文字列参照を使います。</Fragment></Wix>次に、これらの文字列の一覧を記載した地域化ファイルを適切なカルチャで作成します。タグの中で、カルチャとコードページを指定しなければいけません。地域化したい他の言語についても、同様な複製を作って下さい。...</WixLocalization>サンプル・ソース(SampleWixUIAddDlgLoc)からインストーラをビルドするためには、地域化ファイルも参照する必要があります。統合環境では、地域化ファイルは、プロジェクトに含めるだけで、自動的に使用されるようになります。これまでメインのソースに埋め込んでいた日本語のテキストも地域化ファイルに分離しています。そのため、コマンド・ラインで指定しなければならない地域化ファイルの数が、上記のコマンド・ラインの例より増えています。{})で囲む必要があります。Tramontána何よりもコメントと寄稿を歓迎します。softark読みやすくて正確な翻訳を目指しましたが、解釈の誤りと技術的な間違いが含まれていないという保証は出来ません。間違いの指摘や修正案の提示を歓迎します。