• 戻る（XAML）
  • XAMLの書き方（１）
  • XAMLの書き方（２）

基本的な XAML の書き方。

補足（本ページの位置付け）: 本ページは
XAML の言語仕様と WPF の主要機能を、実例と描画結果の図で通しで解説した
大部の資料である（42 点の図を含む）。

【本ページの構成】
   ① 名前空間          … XAML と CLR の対応付け
   ② 言語機能          … ディレクティブ / マークアップ拡張
   ③ プロパティの設定  … 属性構文 / 要素構文 / 型コンバータ
   ④ コンテンツ構文    … Content / Items
   ⑤ リソース          … Static / Dynamic / ディクショナリ
   ⑥ データ バインディング … 11 パターンを実例で
   ⑦ レイアウト        … 6 種のパネル
   ⑧ スタイルとテンプレート
   ⑨ トリガ

WPFのアーキテクチャ が「仕組み」を説明するのに対し、
本ページは「書き方」を扱う——という分担になっている。
併せて読むと理解が進む。

移行メモ（表内のコードをコード ブロックに展開した）: 移行元では、
表のセル内に &br; と   を使ってコードを詰め込んでいた箇所が多い。
これは PukiWiki の制約による書き方であり、
GitHub では可読性が著しく落ちるため、
表は「説明」だけを残し、コード例は表の直後のコード ブロックに展開した。
内容は変更していない。

XAML における各種の名前空間の宣言は、xmlns 属性を使用した XML 名前空間にて行う。
ここでは、以下の既定の名前空間の宣言を例にとって説明する。

• 名前空間の宣言

<Window x:Class="WpfApplication1.Window1"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

• XML名前空間の簡単な説明
  https://www.kanzaki.com/docs/sw/names.html

2 行目の XML 名前空間の宣言
（xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"）では、\ WPF フレームワーク（PresentationFramework.dll）のアセンブリ内に同梱される URI に
マップされた
CLR 名前空間（System.Windows.Controls、System.Windows.Data など）を、
既定の XML 名前空間（プレフィックスなし）として割り当てている。
そのため、既定で XAML から WPF フレームワークの CLR オブジェクトを利用できる。

3 行目の XML 名前空間の宣言（xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"）では、\ URI にマップされた共通的な XAML の言語機能が XML 名前空間（x）として割り当てられている。
これにより、「x:」というプレフィックスを使用することで、
「言語機能」で説明する、XAML の言語機能を使用できるようになる。

補足（この URI は「ただの識別子」である）: 混乱しやすい点なので
明示しておく。

【xmlns の URI は、アクセスしに行かない】★
   http://schemas.microsoft.com/winfx/2006/xaml/presentation
     → 【ブラウザで開いても何もない】
     → XML 名前空間の【一意な識別子】としてのみ使われる

【では、どこで CLR 名前空間と対応付くのか】
   アセンブリに付与された【XmlnsDefinitionAttribute】★
     [assembly: XmlnsDefinition(
         "http://schemas.microsoft.com/winfx/2006/xaml/presentation",
         "System.Windows.Controls")]
     → 1 つの URI に【複数の CLR 名前空間】を割り当てられる
     → だから <Button> と書くだけで型が解決される

【2006 という年号が入っている理由】
   ・XAML の仕様が策定された年
   ・【現在も同じ URI が使われている】（変更されない）
   ・WinUI 3 / MAUI は別の URI を使う
       http://schemas.microsoft.com/winfx/2006/xaml/presentation（WPF）
       http://schemas.microsoft.com/dotnet/2021/maui（MAUI）

CLR 名前空間について以下を例にとって説明する。

• CLR 名前空間の宣言

<Window x:Class="WpfApplication1.Window1"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:igDP="http://infragistics.com/DataPresenter" <--- 名前空間の宣言（追加
  Title="Window1" Height="300" Width="300">
  <Grid>
    <igDP:XamDataGrid Name="xamDataGrid1"/> <--- 名前空間の使用例
  </Grid>
</Window>

Infragistics 社製の NetAdvantage など、

XmlnsDefinition アセンブリ属性で URI と CLR 名前空間のマップが指定された
サードパーティ製の UI コンポーネントを D&D で VS デザイナから追加した場合、

上記の例のように自動的に XML 名前空間の宣言が追加される。

• Microsoft Learn > .NET Framework クラス ライブラリ >
  System.Windows.Markup.XmlAttributeProperties.XmlnsDefinition プロパティ
  https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.markup.xmlattributeproperties.xmlnsdefinition

なお、XML 名前空間には一意の名前を自由に付与でき（上記の例では igDP）、
このプレフィックスを使用することで、XAML から UI コンポーネントの
CLR オブジェクトを利用できる。

この他に、URI として CLR 名前空間とアセンブリを直接指定する方法もある。

• CLR 名前空間の宣言

xmlns:sys="clr-namespace:（CLR名前空間）;assembly=（アセンブリ名）"

• 例１：サードパーティ製品

<Window x:Class="WpfApplication1.Window1"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:igDP="clr-namespace:Infragistics.Windows.DataPresenter;assembly=Infragistics3・・・" <--- 名前空間の宣言
  Title="Window1" Height="300" Width="300">
  <Grid>
    <igDP:XamDataGrid Name="xamDataGrid1"/> <--- 名前空間の使用例

• 例２：.NET Framework

<Window x:Class="WpfApplication1.Window1"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:sys="clr-namespace:System;assembly=mscorlib" <--- 名前空間の宣言
  Title="Window1" Height="300" Width="300">
  <Window.Resources>
    <x:Array x:Key="List" Type="{x:Type sys:String}"> <--- 名前空間の使用例

• 例３：自作の同一プロジェクトのクラス

<Window x:Class="WpfApplication1.Window1"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:uc="clr-namespace:WpfApplication1" <--- 名前空間の宣言
  Title="Window1" Height="300" Width="300">
  <StackPanel Orientation="Vertical">
    <uc:UserControl1 x:Name="userControl1"/> <--- 名前空間の使用例

• この方法では、「clr-namespace」、「assembly」などの定義済みトークンを使用する。

  • 当該プロジェクト中の CLR 名前空間を指定する場合は、「assembly」トークンは省略できる。
  • XML 名前空間には一意の名前を自由に付与でき、
    このプレフィックスを使用することで、
    XAML から UI コンポーネントの CLR オブジェクトを利用できる。

• 製品並みのカスタムの UI コントロールを開発・使用するなどの目的を除いて、
  CLR クラスを開発し XAML から使用する場合、

  • 一般的には「clr-namespace、assembly」の定義済みトークンを使用する。
  • ただし、この方法は、１つの CLR 名前空間に対して、
    １つの XML 名前空間しか割り当てられない
  • （XmlnsDefinition アセンブリ属性を使用すると、
    １つの XML 名前空間に複数の CLR 名前空間を割り当てられる）。

補足（現在の書き方 ── XAML 名前空間の短縮記法）: .NET Core 3.0 以降の WPF /
Visual Studio 2019 以降のテンプレートでは、
より短い記法が使われる。

<!-- 現在のテンプレートが生成する形 ★ -->
<Window xmlns:local="clr-namespace:WpfApp1"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        mc:Ignorable="d">

プレフィックス	用途
（なし）	WPF の標準コントロール
x:	XAML の言語機能（x:Name、x:Key 等）
local:	同一プロジェクトの型（慣習的な名前）
d:	デザイン時専用（VSデザイナの問題 参照）
mc:	マークアップ互換性（mc:Ignorable="d" で d: を実行時に無視）
sys:	clr-namespace:System;assembly=mscorlib

【mc:Ignorable="d" の意味】★
   「d: 名前空間は、理解できなければ【無視してよい】」
     → デザイナは d: を解釈する（ダミー データを表示）
     → 実行時の XAML パーサは無視する
     → 【1 つの XAML でデザイン時と実行時を両立させる】

移行メモ（mscorlib について）: .NET Core 以降、
mscorlib は型フォワーディング用の互換アセンブリになったが、
clr-namespace:System;assembly=mscorlib は現在も動作する。
より正確に書くなら assembly=System.Runtime である。

• Microsoft Learn > WPF の基礎 > WPF の XAML >
  XAML 名前空間および WPF XAML の名前空間の割り当て
  https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/advanced/xaml-namespaces-and-namespace-mapping-for-wpf-xaml

XAML の言語機能である

• ディレクティブ
• マークアップ拡張

について説明する。

• Microsoft Learn > .NET Framework XAML サービスの概念説明のドキュメント >
  XAML 名前空間 (x:) 言語機能
  https://learn.microsoft.com/ja-jp/dotnet/desktop/xaml-services/xaml-namespace-x-language-features

XAML の言語機能が提供する各種ディレクティブについて説明する。

各ディレクティブの記述例を以下に示す。

• 1. x:Class

<Window x:Class="WpfApplication1.Window1"

• 4. x:Code

<Grid>
  <x:Code>
    <![CDATA[
      void button1_Click(object sender, RoutedEventArgs e) {
        button1.Content = "Hello World";
      }
    ]]>
  </x:Code>
  <Button Name="button1" Click="button1_Click">Button</Button>
</Grid>

• 6. x:Key
     下記は、x:Key を使用して「スタイル」の「リソース」をボタンに「データ バインディング」する例。

<Window.Resources>
  <Style x:Key="buttonStyle" TargetType="{x:Type Button}">
    <Setter Property="Background" Value="LightYellow" />
  </Style>
</Window.Resources>
<Grid>
  <Button Style="{StaticResource buttonStyle}">Hello Style</Button>
</Grid>

• 7. x:Name

<Button x:Name="button1">
   Click Here
</Button>

• 9. x:TypeArguments

<!-- XAML 2009 -->
<ObservableCollection x:TypeArguments="Employee">
  <l:Employee FirstName="John" Name="Doe" />
  <l:Employee FirstName="Tim" Name="Smith" />
</ObservableCollection>

• 11. xml:lang

<Window x:Class="WpfApplication1.Window1"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xml:lang="ja-JP"

• Microsoft Learn > Windows Presentation Foundation > グローバライズとローカライズ >
  WPF のグローバリゼーション
  https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/advanced/globalization-for-wpf

補足（x:Name と Name の違い ── 「差異は無い」は条件付き）: 原文の
「Name 属性と差異は無い」は、WPF のほとんどの要素については正しいが、
厳密には違うので補足しておく。

【Name】
   FrameworkElement が持つ【依存関係プロパティ】
     → Name プロパティを持つ型でしか使えない

【x:Name】★
   XAML の【言語機能】（ディレクティブ）
     → 【どんな型でも使える】
     → RuntimeNameProperty 属性があれば、Name プロパティにも代入される

【使い分け】
   ・FrameworkElement 派生 … どちらでもよい（慣習的に x:Name）
   ・Storyboard、Brush 等   … 【x:Name しか使えない】
   ・ジェネリック型         … x:Name

【x:Name を付けると何が起きるか】
   ・.g.cs（生成コード）に【フィールドが生成される】★
     → コードビハインドから参照できるのはこのため
   ・NameScope に登録される
     → FindName() で引ける
     → Storyboard の TargetName で参照できる

【MVVM では x:Name を減らすのが定石】
   → コードビハインドから触らない＝ バインディングで済ませる

xml:lang は国際化で重要である。

【xml:lang="ja-JP" の効果】★
   ・数値・日付の書式（[カルチャ](MS_Culture)）
   ・【フォントの選択】（CJK の字形が言語で変わる）
      → 中国語・日本語・韓国語で「直」「骨」等の字形が違う
      → 指定しないと en-US 扱いになり、【中国語の字形で表示される】
   ・ハイフネーション、行分割の規則

 → 日本語アプリでは【必ず指定する】
 → [国際化対応項目](MS_InternationalizationItems) も参照

x:Uid はローカライズ用で、
LocBaml ツールによるリソース抽出に使われるが、
現在は リソースファイル（.resx）＋
バインディングで対応する方が一般的である。

XAML の言語機能が提供する各種「マークアップ拡張」について説明する。
通常、「マークアップ拡張」は、「{」と「}」の２つの中括弧を使用することで
XAML パーサに対し、拡張されたプロパティ指定方法を指示する。

• Microsoft Learn > WPF の基礎 > WPF の XAML
  • マークアップ拡張機能と WPF XAML
    https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/advanced/markup-extensions-and-wpf-xaml
  • WPF XAML 拡張機能
    https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/advanced/wpf-xaml-extensions

以下、XAML の機能である「XAML で定義されたマークアップ拡張」を一覧する。
これらの種類は、中括弧＋「x:」プレフィックスの直後の文字列トークンによって識別される。

• XAML に実装されたマークアップ拡張

各マークアップ拡張の記述例を以下に示す。

• 1. x:Static

<Button 
    Foreground="{x:Static Member=SystemColors.InfoTextBrush}"
    Background="{x:Static Member=SystemColors.InfoBrush}">
  Click Here
</Button>

• 2. x:Null

<Button x:Name="button1" Background="{x:Null}" Click="button1_Click">
  Click Here
</Button>

• 3. x:Type
     詳しくは、下記、項番 4 の例を参照のこと。
• 4. x:Array

<Window.Resources>
  <x:Array x:Key="List"
    Type="{x:Type sys:String}">
    <sys:String>A</sys:String>
    <sys:String>B</sys:String>
    <sys:String>C</sys:String>
  </x:Array>
</Window.Resources>
<StackPanel>
  <ListBox ItemsSource="{Binding Source={StaticResource List}}"/>
</StackPanel>

※ 先頭で、.NET Framework の System 名前空間のインポートが必要
　xmlns:sys="clr-namespace:System;assembly=mscorlib"

※ StaticResource については次項で説明する。

※ x:Array は、例外的に中括弧と共に使用しない。

補足（マークアップ拡張の正体）: 「中括弧で囲む」という見た目の裏に
あるものを補っておく。

【マークアップ拡張は「クラス」である】★
   {Binding Path=Name}
     → new System.Windows.Data.Binding { Path = new PropertyPath("Name") }
        .ProvideValue(serviceProvider)

   ・MarkupExtension を継承したクラス
   ・ProvideValue メソッドの戻り値が、実際に設定される値
   ・クラス名の末尾の "Extension" は省略できる
       BindingExtension → {Binding}

// 自作のマークアップ拡張も作れる
public class NowExtension : MarkupExtension
{
    public override object ProvideValue(IServiceProvider sp) => DateTime.Now;
}
// <TextBlock Text="{local:Now}" />

【中括弧をエスケープする】★
   値が { で始まる場合、マークアップ拡張と誤解される
     <TextBlock Text="{}{0} 円" />
                       ↑ {} で「これは拡張ではない」と示す
   → StringFormat でよく使う

x:Static の実用的な使いどころ:

<!-- 定数・列挙値を XAML から参照する -->
<TextBlock Text="{x:Static local:AppInfo.Version}" />
<Button Visibility="{x:Static Visibility.Collapsed}" />

<!-- [リソースファイル](MS_ResourceFiles) の文字列を参照する（国際化） -->
<Button Content="{x:Static props:Resources.SaveButtonText}" />

【x:Static の限界】★
   ・【静的な値を 1 回読むだけ】＝ 変更通知がない
   ・→ 実行時に言語を切り替えても【再読み込みされない】
   ・→ 動的な切り替えが必要なら、
     ViewModel 経由でバインドする

以下、WPF の機能である「WPF 固有のマークアップ拡張」を一覧する。
こちらは、プロパティ値に「データ バインディング」や、
「リソース」への参照を指定できる。

• XAML に実装されたマークアップ拡張

各マークアップ拡張の構文を以下に示す。
※ 「プロパティ属性構文」と「プロパティ要素構文」については、後述する。

• 1. {Binding
     具体例は、「データ バインディングの基礎」を参照のこと。
• 2. {StaticResource
     具体例は、「リソースとのデータ バインディング」を参照のこと。
  • プロパティ属性構文：

<object property="{StaticResource key}" .../>

• なお、「データ バインディング」で使用する場合は、次のようになる。

<object property="{Binding Source={StaticResource key} ...}" .../>

• プロパティ要素構文：

<object>
  <object.property>
    <StaticResource ResourceKey="key" .../>
  </object.property>
</object>

• 3. {DynamicResource
     具体例は、「リソースとのデータ バインディング」を参照のこと。
  • プロパティ属性構文：

<object property="{DynamicResource key}" .../>

• なお、「データ バインディング」で使用する場合は、次のようになる。

<object property="{Binding Source={DynamicResource key} ...} " .../>

• プロパティ要素構文：

<object>
  <object.property>
    <DynamicResource ResourceKey="key" .../>
  </object.property>
</object>

• 4. {TemplateBinding
     具体例は、「テンプレート」を参照のこと。
  • プロパティ属性構文：

<object property="{TemplateBinding TargetProperty }" .../>

• 5. {RelativeSource
     具体例は、後述の「RelativeSource の例」を参照のこと。
  • プロパティ属性構文：

<Binding RelativeSource="{RelativeSource modeEnumValue}" .../>

• なお、「データ バインディング」で使用する場合は、次のようになる。

<object property="{Binding RelativeSource={RelativeSource modeEnumValue} ...}" .../>

• プロパティ要素構文：

<Binding>
  <Binding.RelativeSource>
    <RelativeSource Mode="modeEnumValue"/>
  </Binding.RelativeSource>
</Binding>
 OR 
<Binding>
  <Binding.RelativeSource>
    <RelativeSource
      Mode="FindAncestor"
      AncestorType="{x:Type typeName}"
      AncestorLevel="intLevel"/>
  </Binding.RelativeSource>
</Binding>

※ key には、x:Key ディレクティブによって指定された既存のリソースに対応するキーを指定する。

移行メモ（RelativeSource の要素構文の綴り）: 原文の 2 つ目の
プロパティ要素構文の例では <Relative となっていたが、
正しくは <RelativeSource である（上のコードでは修正済み）。

補足（StaticResource と DynamicResource の使い分け）: この 2 つの違いは
WPF で最も重要な選択の 1 つなので、先に整理しておく
（詳細は後述の「リソース」節）。

	StaticResource	DynamicResource
解決のタイミング	XAML 読み込み時に 1 回	実行時、参照のたび
変更の反映	されない	される ★
速度	速い	遅い（参照を保持する）
前方参照	できない（定義が先に必要）	できる
使える対象	何でも	依存関係プロパティのみ ★

【判断】
   ・原則【StaticResource】（速い）★
   ・テーマの動的切り替え、システム色への追従が要るときだけ
     DynamicResource
   ・SystemColors、SystemParameters は DynamicResource が推奨

後述の「Binding オブジェクトをバインディングのマークアップ拡張で実装する」を参照。

後述の「『テンプレート』値を反映させる方法」を参照。

後述の「『テンプレート』値を反映させる方法」を参照。

プロパティの設定方法として、

• プロパティ属性構文：
  要素の属性にテキストを使用して設定する。
• プロパティ要素構文：
  要素の innerText・innerXML を使用してプロパティを設定する。

の２つの構文について説明する。

以下、TextBox 要素に対して、同等の属性を設定する
「プロパティ属性構文」と「プロパティ要素構文」の例を示す。

要素の属性にテキストを使用してプロパティを設定する方法

• プロパティ属性構文の例

<TextBox 
   Width = "100"
   FontSize = "30"
   Text = "text1"
   Background = "White"
   Foreground = "Blue" />

要素の innerText・innerXML を使用してプロパティを設定する方法

• プロパティ要素構文の例

<TextBox>
  <TextBox.Width>100</TextBox.Width>
  <TextBox.FontSize>30</TextBox.FontSize>
  <TextBox.Background>
    <SolidColorBrush Color="White"/>
  </TextBox.Background>
  <TextBox.Foreground>
    <SolidColorBrush Color="Blue"/>
  </TextBox.Foreground>
  <TextBox.Text>text1</TextBox.Text>
</TextBox>

なお、子要素のコレクションを設定する「プロパティ要素構文」である

• Panel.Children プロパティ
• ItemsControl.Items プロパティ

などは、暗黙的に使用されるため明記が不要のものもある。

補足（どちらを使うかの判断）: 2 つの構文は等価ではない。

【プロパティ属性構文で書けるもの】
   文字列から【型コンバータで変換できる】値だけ ★
     Width="100"        → double
     Background="White" → Brush（BrushConverter が変換）

【プロパティ要素構文が必要になるもの】
   ・文字列で表せない複雑なオブジェクト
       <Button.Background>
         <LinearGradientBrush>...</LinearGradientBrush>
       </Button.Background>
   ・子要素のコレクション
   ・テンプレート、スタイル

【実務での書き分け】
   ・単純な値 → 属性構文（1 行で読める）★
   ・複雑な値 → 要素構文
   → 【混在させてよい】（同じ要素で両方使える）

XAML パーサは、XAML の「プロパティ属性構文」として指定された各属性テキストを、
プリミティブ型に変換できるリテラル文字列として解釈するか、
「型コンバータ」を使用してオブジェクトに変換する。

なお、「型コンバータ」（と、そのベース クラスである TypeConverter クラス）は、
.NET のコンポーネントとコントロールのデザイン時・実行時の動作を実装する一般的なクラスであり、
WPF 独自のクラスではない。
しかし、XAML の「プロパティ属性構文」からの CLR プロパティ設定を多用する
WPF / Silverlight 開発では、その存在を認識しておいたほうが良い。

XAML パーサは通常、プロパティの型（CLR クラス）に TypeConverterAttribute 属性が
付与されているかを調べる。
付与されている場合は、この属性値に基づいた「型コンバータ」を使って、
TypeConverter.ConvertFrom メソッドにより文字列をプロパティ値に変換する。

以下は、ユーザ コントロールに、MyPoint というカスタムの型を取る CLR プロパティを
実装し XAML に公開、
XAML の「プロパティ属性構文」として指定された各属性テキストを、
カスタムの型に変換する「型コンバータ」を実装した例である。

MyPoint というカスタム型（型コンバータを実装）

/// <summary>
/// カスタム型（型コンバータを実装）
/// </summary>
[TypeConverter(typeof(MyPointConverter))]
public class MyPoint {
  public MyPoint(int x, int y) {
    this._x = x;
    this._y = y;
  }
  private int _x;
  public int X {
    set { this._x =value; }
    get { return this._x; } 
  }
  private int _y;
  public int Y {
    set { this._y = value; }
    get { return this._y; }
  }
}

/// <summary>カスタム型の型コンバータ</summary>
public class MyPointConverter : TypeConverter {

  /// <summary>CanConvertFrom（変換可能かチェックする）</summary>
  public override bool CanConvertFrom(
    ITypeDescriptorContext context, Type sourceType) {
    if (sourceType == typeof(string)) {
      return true;
    }
    return base.CanConvertFrom(context, sourceType);
  }

  /// <summary>指定された文字列をカスタム型（MyPoint）に変換する</summary>
  public override object ConvertFrom(
    ITypeDescriptorContext context,
    CultureInfo culture, object value) {
    if (value is string) {
      string[] v = ((string)value).Split(new char[] { ',' });
      return new MyPoint(int.Parse(v[0]), int.Parse(v[1]));
    }
    return base.ConvertFrom(context, culture, value);
  }

  /// <summary>指定されたカスタム型（MyPoint）を文字列に変換する</summary>
  public override object ConvertTo(ITypeDescriptorContext context,
    CultureInfo culture, object value, Type destinationType) {
    if (destinationType == typeof(string)) {
      return ((MyPoint)value).X + "," + ((MyPoint)value).Y;
    }
    return base.ConvertTo(context, culture, value, destinationType);
  }
}

MyPoint というカスタム型の CLR プロパティを実装

/// <summary>
/// UserControl1.xaml の相互作用ロジック
/// </summary>
public partial class UserControl1
  : UserControl {
  // CLRプロパティの定義（XAML属性に公開可能）
  private MyPoint _myLocation;

  public MyPoint MyLocation {
    set { this._myLocation = value; }
    get { return this._myLocation; }
  }

・・・

上記のユーザ コントロールのカスタムの型を取る CLR プロパティを、
以下のように XAML の「プロパティ属性構文」として指定された
各属性テキストから初期化できる。

<uc:UserControl1 x:Name="userControl1" MyLocation="10,20"/>

ただし、(当然ながら、)文字列からの変換をサポートしているだけで、
すべてのプロパティ値をサポートすることはできない。
文字列で表現できないプロパティ値は、「プロパティ属性構文」ではなく
「プロパティ要素構文」として記述する方法を取る。

• Microsoft Learn > WPF の基礎 > WPF の XAML > TypeConverters 及び XAML
  https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/advanced/typeconverters-and-xaml

補足（型コンバータ実装時の注意点）: サンプルは要点を押さえているが、
実務で追加すべき点を挙げておく。

// ① CultureInfo を尊重する ★
//    "10,20" の "," は、文化圏によっては小数点である
//    → InvariantCulture で解釈するのが安全
int.Parse(v[0], CultureInfo.InvariantCulture);

② 【CanConvertTo も実装する】
   ConvertTo を実装するなら、対で CanConvertTo も要る

③ 【変換失敗時は例外を投げる】
   → XAML パーサが XamlParseException に包んで
     【行番号付きで】報告してくれる
   → null を返すと、原因が分からなくなる

④ 【デザイン時にも呼ばれる】★
   → [VSデザイナの問題](MS_VSDesignerProblem) 参照
   → 外部リソースに触らない

【型コンバータ vs マークアップ拡張】★
   型コンバータ     … 【文字列 → 値】の変換（MyLocation="10,20"）
   マークアップ拡張 … 【任意の処理】で値を作る（{Binding ...}）

 → 「文字列で簡潔に書きたい」なら型コンバータ
 → 「他のオブジェクトを参照したい」ならマークアップ拡張

移行メモ（依存関係プロパティにすべき場面）: サンプルの
MyLocation は CLR プロパティとして実装されているが、
バインディング・スタイル・アニメーションの対象にするなら
依存関係プロパティにする必要がある
（WPFのコントロール /
WPFのアーキテクチャ 参照）。
型コンバータの説明としては CLR プロパティで十分である。

「コンテンツ構文」とは、Content プロパティ（または Items プロパティ）に
要素を設定する構文である。

• ContentPropertyAttribute を付けることで、

  • Microsoft Learn > .NET Framework クラス ライブラリ >
    System.Windows.Markup.ContentPropertyAttribute クラス
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.markup.contentpropertyattribute
    • [ContentPropertyAttribute("Content")] → Content プロパティ
    • [ContentPropertyAttribute("Items")] → Items プロパティ

• 属性に指定される Content プロパティを、
  innerText・innerXML（プロパティ要素構文）として記述できるようになる。

  • コンテンツ構文
    • プロパティ属性構文

<Button Content="Click Here" />

- プロパティ要素構文

<Button>Click Here</Button>

• 比較

  • なお、Windows Forms や Web Forms（HTML）などで、
    UI コントロールの表示のカスタマイズをするには、
    UI コントロールの「スタイル」属性の指定による方法のみサポートされていた。
  • これに対し、WPF の UI コントロールは「スタイル」属性の指定による方法だけでなく、
    Content プロパティ（または Items プロパティ）に任意の型の子要素を設定することが
    できるため、
    コントロールの「外観」を自由に変更でき、柔軟性が非常に高くなっている。

• 補足：Windows フォームの外観の変更

  • コントロールを自前で描画する「オーナー描画」と呼ばれる方法が用意されていたが、
    「オーナー描画」はグラフィックス メソッドなどを使用して、
    すべての描画を独自に行わなければならないため、深い知識と多量のコードが必要であった。

  • 関連資料

    • .NETコントロールのカスタマイズ方法

WPF の ContentControl は、

• ContentControl.Content プロパティに設定された単一の要素を表示するという機能を提供する
  コントロール
• ContentControl.Content プロパティに任意の型の子要素を設定することができるため、
  コントロールの「外観」を自由に変更できる。
• 従って、ContentControl を継承する Button クラスや Label クラスなどなどでは
  コントロールの「外観」を自由に変更できる。
  • Control.Template プロパティ
  • ContentControl.ContentTemplate プロパティ

WPF の ContentControl の Button コントロールを例にして
Content プロパティへ要素を設定する例を示す。

• XAML
  • プロパティ属性構文：

<Button Width="200" Height="200" Content="ボタン"/>

• プロパティ要素構文：

<Button Width="200" Height="200">ボタン</Button>

• レンダリング結果

Content プロパティには、Image オブジェクトなどの任意の型の要素も設定できる。

• XAML

<Button Width="200" Height="200">
  <Button.Content>
    <Image Source=".\Blue hills.jpg"/>
  </Button.Content>
</Button>

• レンダリング結果

• XAML
  • 2 つ以上の要素を設定したい場合は、パネル要素を使用する。

<Button Width="200" Height="200">
  <Button.Content>
    <StackPanel Orientation="Vertical">
      <Image Source=".\Blue hills.jpg" Margin="5" />
      <TextBlock Text="ボタン" HorizontalAlignment="Center" Margin="5"/>
    </StackPanel>
  </Button.Content>
</Button>

• なお、<Object.Content> タグは省略することもできる。

<Button Width="200" Height="200">
  <StackPanel Orientation="Vertical">
    <Image Source=".\Blue hills.jpg" Margin="5" />
    <TextBlock Text="ボタン" HorizontalAlignment="Center" Margin="5"/>
  </StackPanel>
</Button>

• レンダリング結果

補足（「Content は 1 つだけ」という制約の意味）: 「2 つ以上の要素を
設定したい場合はパネル要素を使用する」という記述は、
WPF の設計上、非常に重要な帰結である。

【Content は object 型のプロパティ 1 つ】
   → 【2 つ入れることは原理的にできない】
   → だから「1 つのパネルに入れてから渡す」

【これが XAML のツリー構造を単純に保っている】★
   ・どの要素も「Content が 1 つ」か「Items が複数」か
   ・その 2 種類しかない
   → パーサも、レイアウトも、単純になる

【余分な入れ子のコスト】
   Button > StackPanel > Image + TextBlock
     → 要素が 1 つ増えると、Measure/Arrange も増える
     → 大量に並べる場合は【要素数を減らす】ことが性能に効く
     → [WPFのアーキテクチャ](MS_WPFArchitecture) のレイアウト 2 パスを参照

WPF の ItemsControl は、Items プロパティに任意の型の子要素を設定することが
できるため、コントロールの「外観」を自由に変更できる。

ItemsControl の Items プロパティへは、複数のコンテンツを追加できる。
以下、ListBox コントロールを例にして Items プロパティへ子要素の設定する例を示す。

• XAML

<Grid>
  <ListBox>
    <Border BorderBrush ="Black" BorderThickness ="1" Margin="5">
      <StackPanel Orientation="Horizontal" Height="120" Width="250" Margin="5">
        <Image Source=".\Blue hills.jpg" Height="100"/>
        <TextBlock Text="Blue hills" VerticalAlignment="Center"/>
      </StackPanel>
    </Border>
    <Border BorderBrush ="Black" BorderThickness ="1" Margin="5">
      <StackPanel Orientation="Horizontal" Height="120" Width="250" Margin="5">
        <Image Source=".\Sunset.jpg" Height="100"/>
        <TextBlock Text="Sunset" VerticalAlignment="Center"/>
      </StackPanel>
    </Border>
    <Border BorderBrush ="Black" BorderThickness ="1" Margin="5">
      <StackPanel Orientation="Horizontal" Height="120" Width="250" Margin="5">
        <Image Source=".\Water lilies.jpg" Height="100"/>
        <TextBlock Text="Water lilies" VerticalAlignment="Center"/>
      </StackPanel>
    </Border>
    <Border BorderBrush ="Black" BorderThickness ="1" Margin="5">
      <StackPanel Orientation="Horizontal" Height="120" Width="250" Margin="5">
        <Image Source=".\Winter.jpg" Height="100"/>
        <TextBlock Text="Winter" VerticalAlignment="Center"/>
      </StackPanel>
    </Border>
  </ListBox>
</Grid>

• レンダリング結果

• 説明
  • Items プロパティに子要素を設定する場合は、
    innerText・innerXML を使用する「プロパティ要素構文」を使用する。
    • また、この際に <Object.Items> タグは省略することもできる。
  • ちなみに、上記を「データ バインディング」で実装することもできる。
    • これについては、「データ バインディングの基礎」を参照のこと。

補足（この書き方は実務では使わない）: 原文自身が
「データ バインディングで実装することもできる」と補足している通り、
XAML に項目を直接書く方式は、実務ではまず使わない。

【XAML に直接書く方式の問題】★
   ・データが増えると XAML が膨れ上がる
   ・データが動的なら書けない
   ・【同じマークアップを項目数だけ繰り返す】＝ 重複
   ・仮想化が効かない（全項目が実体化される）

【正しい書き方】
   ItemsSource でコレクションをバインドし、
   ItemTemplate で「1 件の見た目」を 1 回だけ定義する ★

<ListBox ItemsSource="{Binding Photos}">
  <ListBox.ItemTemplate>
    <DataTemplate>
      <Border BorderBrush="Black" BorderThickness="1" Margin="5">
        <StackPanel Orientation="Horizontal" Height="120" Width="250" Margin="5">
          <Image Source="{Binding Path}" Height="100"/>
          <TextBlock Text="{Binding Title}" VerticalAlignment="Center"/>
        </StackPanel>
      </Border>
    </DataTemplate>
  </ListBox.ItemTemplate>
</ListBox>

本節は「Items に何でも入る」ことを示す説明として読み、
実装は後述の ItemTemplate 方式を採るのがよい。

ここでは、

• 「リソース」の定義方法と、

• 前述の各「マークアップ拡張」を使用し、
  プロパティ値に「リソース」への参照を指定する方法

について説明する。

※「リソース」の「データ バインディング」については、
「リソースとのデータ バインディング」を参照のこと。

• 参考
  • Microsoft Learn > WPF の基礎 > リソース
    https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/advanced/xaml-resources

「リソース」とは、ResourceDictionary 型のオブジェクトであり、

• Application オブジェクトの Resources プロパティ
• 各 UI 要素（FrameworkElement or FrameworkContentElement）の Resources プロパティ

に「プロパティ要素構文」を使用して定義できる。

• Microsoft Learn > .NET Framework クラス ライブラリ
  • System.Windows.ResourceDictionary クラス
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.resourcedictionary
  • System.Windows.Application.Resources プロパティ
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.application.resources
  • System.Windows.FrameworkElement.Resources プロパティ
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.frameworkelement.resources
  • System.Windows.FrameworkContentElement.Resources プロパティ
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.frameworkcontentelement.resources

このため、任意の UI 要素に定義可能であるが、
通常はルート要素（Window or Page）上に定義する。

また、「リソース」は、定義場所により以下のような呼称・特徴がある。

• アプリケーション リソース
  Application オブジェクトの Resources プロパティに定義された「リソース」を
  「アプリケーション リソース」と呼び、
  全体から（つまりどこからでも）参照できるという特徴を持っている。

• ウィンドウ ページ リソース
  Window・Page オブジェクトの Resources プロパティに定義された「リソース」を
  「アプリケーション リソース」と呼び、
  その Window・Page と、その子要素から参照できるという特徴を持っている。

• イミディエイト リソース
  各 UI 要素（FrameworkElement or FrameworkContentElement）の
  Resources プロパティに定義された「リソース」を「イミディエイト・リソース」と呼び、
  「リソース」を定義した要素と、その子要素から参照できるという特徴を持っている。

移行メモ（2 つ目の呼称が誤り）: 「ウィンドウ ページ リソース」の説明で、
**「『アプリケーション リソース』と呼び」となっているが、
見出しの通り「ウィンドウ ページ リソース」**が正しい
（1 つ目からのコピー時の誤りと読める）。

補足（リソース検索の順序）: 3 つの定義場所の違いは、
検索順序として理解すると分かりやすい。

【リソースが検索される順序】★

  参照した要素の Resources
    ↓ 見つからなければ
  その親要素の Resources
    ↓ ……（論理ツリーを遡る）
  Window / Page の Resources
    ↓
  Application.Resources
    ↓
  テーマのリソース（Themes/Generic.xaml、システムテーマ）
    ↓
  見つからなければ
    StaticResource  → 【例外】★
    DynamicResource → 既定値（何も起きない）

【設計の指針】
   ・全画面で使う色・スタイル → App.xaml（アプリケーション リソース）
   ・その画面だけの定義       → Window.Resources
   ・その要素の中だけ         → 要素の Resources

 → 【スコープを最小にする】のが原則
 → App.xaml に全部書くと、名前の衝突と読み込みコストが増える

• 「リソース」には、前述の x:Key ディレクティブを使用して
  一意のキーを持たせて定義する必要がある。

<Window.Resources>
  <x:Array x:Key="List" Type="{x:Type sys:String}">
    <sys:String>A</sys:String>
    <sys:String>B</sys:String>
    <sys:String>C</sys:String>
  </x:Array>
</Window.Resources>

※ 先頭で、String 型のインポートが必要
xmlns:sys="clr-namespace:System;assembly=mscorlib"

• 補足：ジェネリック コレクションのリソース
  ジェネリック コレクションを「リソース」に定義するには、
  x:TypeArguments のディレクティブを使用して、
  ObservableCollection<T> コレクション クラスなどのジェネリック型の
  コンストラクタに渡す必要があるが、
  これは、XAML2009 からのサポートとなる。

「リソース」を定義したら、各種「マークアップ拡張」を使用して、
プロパティ値に「データ バインディング」や、「リソース」への参照を指定できる。

この時、参照する側から x:Key ディレクティブを使用して割り当てたキーを
「リソース」検索のキーとして指定できる。

なお、「スタイル」や「テンプレート」などは、キーを定義せず、
TargetType 属性のみ使用して、
指定の型のオブジェクトに「スタイル」や「テンプレート」を適用することもできる。
これについては、「スタイルとテンプレート」を参照のこと。

• Microsoft Learn > .NET Framework クラス ライブラリ
  • System.Windows.Style.TargetType プロパティ
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.style.targettype
  • System.Windows.Controls.ControlTemplate.TargetType プロパティ
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.controls.controltemplate.targettype

以下、「リソース」の定義と、プロパティ値に「リソース」への参照を指定する例を示す。

StaticResource 参照では、

• コンパイル時に「リソース」検索が行われ、
  各「リソース」に指定されたキーが存在するかどうかが確認される。
• 「リソース」検索により、「リソース」が発見できなかった場合は、
  コンパイル時にエラーとなる。

以下は、StaticResource の定義と参照例。

• XAML
  • StaticResource の定義と参照例（１）
    • 以下は、「マークアップ拡張」を使用して、
      「プロパティ属性構文」で StaticResource 参照した例である。
    • また、属性名を省略すると自動的にコンストラクタに渡される動作を利用して、
      ResourceKey 属性に指定の値を渡す旨を指示する「ResourceKey=」という記述を
      省略することができる。

<Window.Resources>
  <SolidColorBrush x:Key="BlueBrush" Color="Blue"/>
</Window.Resources>
<Grid>
  <Ellipse Fill="{StaticResource ResourceKey=BlueBrush}" Height="150" Width="150"/>
</Grid>

↓ 「ResourceKey =」という記述を省略

<Window.Resources>
  <SolidColorBrush x:Key="BlueBrush" Color="Blue"/>
</Window.Resources>
<Grid>
  <Ellipse Fill="{StaticResource BlueBrush}" Height="150" Width="150"/>
</Grid>

• StaticResource の定義と参照例（２）
  以下は、一般的ではないが「プロパティ要素構文」を使用して
  StaticResource 参照した例である。
  なお、WPF のみ、StaticResource 参照を「プロパティ要素構文」で記述可能である。

<Window.Resources>
  <SolidColorBrush x:Key="BlueBrush" Color="Blue"/>
</Window.Resources>
<Grid>
  <Ellipse Height="150" Width="150">
    <Ellipse.Fill>
      <StaticResource ResourceKey="BlueBrush"/> 
    </Ellipse.Fill>
  </Ellipse>
</Grid>

• レンダリング結果

移行メモ（「コンパイル時にエラーとなる」は正確でない）: StaticResource の
解決は**コンパイル時ではなく、XAML の読み込み時（実行時）**に行われる。

【実際の挙動】★
   ・ビルドは通る
   ・【実行時（InitializeComponent 時）に XamlParseException】
      「'StaticResource' の指定した値は無効です」
      → 内部例外に「リソース参照が見つかりません」

【ただし】
   ・Visual Studio のデザイナ／エディタは
     【編集中に波線で警告してくれる】
   ・原文の「コンパイル時に確認される」は、
     この体験を指していると読める

【前方参照ができない点は正しい】★
   <Grid>
     <Ellipse Fill="{StaticResource BlueBrush}" />   ← ここで解決を試みる
   </Grid>
   <Window.Resources>                                 ← まだ読まれていない
     <SolidColorBrush x:Key="BlueBrush" .../>
   </Window.Resources>
     → 【失敗する】
     → リソースは【参照より前に定義する】
     → DynamicResource なら前方参照できる

• DynamicResource 参照では、アプリケーションの起動時に、
  後で「リソース」検索を行う際に使用する一時的な式が作成され、
  アプリケーションの実行後、「リソース」が必要になった際に都度、
  「リソース」検索が行われる。

• このため DynamicResource 参照は、

  • 主に「リソース」の値が変更される場合、StaticResource 参照に代替して使用する。
  • 「リソース」検索により、「リソース」が発見できなかった場合は、
    デフォルト値が設定される。

• なお、DynamicResource 参照は、WPF でのみ利用可能で、
  「Silverlight」では利用不可である。

以下は、DynamicResource の定義と参照例。

• 以下は、リソースがアプリケーション外部から変更される場合の例
  以下は、デスクトップ画面のテーマの変更（Windows XP → Windows クラシック）を
  反映する例である。

<Grid>
  <Grid.RowDefinitions>
    <RowDefinition/>
    <RowDefinition/>
  </Grid.RowDefinitions>
  <Ellipse Grid.Row="0"
    Fill="{StaticResource ResourceKey={x:Static SystemColors.HighlightBrushKey}}"/>
  <Ellipse Grid.Row="1"
    Fill="{DynamicResource ResourceKey={x:Static SystemColors.HighlightBrushKey}}"/>
</Grid>

• 以下は、リソースがアプリケーション内部から変更される場合の例
  以下は、アプリケーションからの「リソース」の動的な変更を反映する例である。
  なお、「リソース」の動的な変更は、FrameworkElement.Resources プロパティで変更できる。

  • XAML

<Window.Resources>
  <SolidColorBrush x:Key="MyBrush" Color="Blue"/>
</Window.Resources>
<Grid>
  <Grid.RowDefinitions>
    <RowDefinition/>
    <RowDefinition/>
    <RowDefinition Height="23"/>
  </Grid.RowDefinitions>
  <Ellipse Grid.Row="0" Fill="{StaticResource MyBrush}"/>
  <Ellipse Grid.Row="1" Fill="{DynamicResource MyBrush}"/>
  <StackPanel Grid.Row="2" Orientation="Horizontal" HorizontalAlignment="Center">
    <Button Content="青" Height="23" Name="button1" Width="75" Click="button1_Click" />
    <Button Content="赤" Height="23" Name="button2" Width="75" Click="button2_Click" />
  </StackPanel>
</Grid>

• コード ビハインド

private void button1_Click(object sender, RoutedEventArgs e) {
  this.Resources["MyBrush"] = Brushes.Blue;
}
private void button2_Click(object sender, RoutedEventArgs e) {
  this.Resources["MyBrush"] = Brushes.Red;
}

補足（この 2 つの例が示すこと）: 図が示す通り、
上の円（StaticResource）は変わらず、下の円（DynamicResource）だけが変わる——
これが両者の違いを最も端的に表している。

【実務での使い分け】★

 【DynamicResource を使うべき場面】
   ・SystemColors / SystemParameters
       → OS のテーマ変更・ハイコントラスト モードに追従する
       → 【アクセシビリティ対応として重要】★
   ・アプリ内のテーマ切り替え（ダーク／ライト）
   ・スキン差し替え

 【StaticResource で十分な場面】
   ・固定の色・サイズ・スタイル（大半はこちら）
   ・→ 【速い】。参照を保持しないのでメモリも軽い

【DynamicResource の制約】★
   ・【依存関係プロパティにしか設定できない】
      → Setter.Value、通常のプロパティには使えない場合がある
   ・実行時に解決するため、遅い
   ・見つからなくてもエラーにならない
      → 【タイプミスに気付けない】（何も表示されないだけ）

移行メモ（Silverlight について）: 「Silverlight では利用不可」
という記述は当時の事実だが、
Silverlight 自体がサポート終了している
（Silverlight）。

ResourceDictionary は、「ディクショナリ ファイル」に定義することもできる。

「ディクショナリ ファイル」を追加する際は、

1. プロジェクト ファイルを右クリックし、
2. [追加] → [リソース ディクショナリ]を選択するか、
   [追加] → [新しい項目]を選択し、表示されるテンプレートから
   [リソース ディクショナリ（WPF）]を選択する。

• 前述の StaticResource 参照の例を、
  「ディクショナリ ファイル」を使用するように書き直した例を以下に示す。

<ResourceDictionary
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <SolidColorBrush x:Key="BlueBrush" Color="Blue"/>
</ResourceDictionary>

ディクショナリ ファイルの定義例 (Dictionary1.xaml)

• 「ディクショナリ ファイル」を「イミディエイト・リソース」にロードする。

<Window.Resources>
  <ResourceDictionary Source="Dictionary1.xaml"/>
</Window.Resources>
<Grid>
  <Ellipse Fill="{StaticResource BlueBrush}" Height="150" Width="150"/>
</Grid>

StaticResource 参照 ＋ ディクショナリ ファイルの使用例

補足（MergedDictionaries を使うのが実務の定石）: 上記のように
Source を直接指定すると、Resources 全体がそのファイルで置き換わる。
複数のディクショナリを併用するには MergedDictionaries を使う。

<!-- App.xaml（実務での典型） -->
<Application.Resources>
  <ResourceDictionary>
    <ResourceDictionary.MergedDictionaries>
      <ResourceDictionary Source="Themes/Colors.xaml" />
      <ResourceDictionary Source="Themes/Buttons.xaml" />
      <ResourceDictionary Source="Themes/TextBoxes.xaml" />
    </ResourceDictionary.MergedDictionaries>
    <!-- ここに個別のリソースも書ける -->
    <sys:Double x:Key="DefaultFontSize">14</sys:Double>
  </ResourceDictionary>
</Application.Resources>

【MergedDictionaries の注意点】★
 ① 【後勝ち】
      同じキーが複数のファイルにあると、後に読んだ方が有効
 ② 【重複読み込みに注意】
      複数の UserControl が同じ Colors.xaml を Merge すると、
      【その数だけインスタンスが作られる】
      → メモリと起動時間を無駄にする
      → 共通のものは App.xaml で 1 回だけ Merge する
 ③ pack URI で他アセンブリのものも読める
      Source="pack://application:,,,/MyLib;component/Themes/Generic.xaml"

【リソース ディクショナリの分割方針】
   Colors.xaml     … 色（最も差し替えたい）
   Fonts.xaml      … フォント
   Controls/*.xaml … コントロールごとのスタイル
     → テーマ切り替えは Colors.xaml だけ差し替えれば済む ★

• DynamicResource 参照と ResourceDictionary を組み合わせ、
• ResourceDictionary を、Application.LoadComponent で動的にロード、
• Application.Current.Resources に設定することにより、
• 「スタイル」（スキン）などの設定をアプリケーションから動的に変更することが可能である。

以下の、その例を示す。

• Dictionary
  • Dictionary1.xaml

<ResourceDictionary
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <SolidColorBrush x:Key="MyBrush" Color="Blue"/>
</ResourceDictionary>

• Dictionary2.xaml

<ResourceDictionary
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <SolidColorBrush x:Key="MyBrush" Color="Red"/>
</ResourceDictionary>

• XAML

<StackPanel>
  <Ellipse Fill="{DynamicResource MyBrush}" Height="150" Width="150"/>
  <Button Content="青" Height="23" Name="button1" Width="75" Click="button1_Click" />
  <Button Content="赤" Height="23" Name="button2" Width="75" Click="button2_Click" />
</StackPanel>

• コード ビハインド

public partial class Window1 : Window {
  public Window1() {
    InitializeComponent();
    this.LoadResourceDictionary("Dictionary1.xaml");
  }

  private void button1_Click(object sender, RoutedEventArgs e) {
    this.LoadResourceDictionary("Dictionary1.xaml");
  }

  private void button2_Click(object sender, RoutedEventArgs e) {
    this.LoadResourceDictionary("Dictionary2.xaml");
  }

  private void LoadResourceDictionary(string name) {
    ResourceDictionary dictionary =
      (ResourceDictionary)Application.LoadComponent(new Uri(name, UriKind.Relative));
    if (dictionary != null) Application.Current.Resources = dictionary;
  }
}

DynamicResource 参照 ＋ ディクショナリ ファイルの使用例

補足（テーマ切り替えの実装 ── 現在の書き方）: このサンプルは
Application.Current.Resources を丸ごと置き換える方式だが、
他のリソースまで消えてしまうという問題がある。

// ✗ Resources を丸ごと差し替える → 他のスタイル・コンバータも消える ★
Application.Current.Resources = dictionary;

// ○ MergedDictionaries の特定の 1 つだけを差し替える
void SwitchTheme(string name)
{
    var merged = Application.Current.Resources.MergedDictionaries;
    var old = merged.FirstOrDefault(
        d => d.Source?.OriginalString.Contains("Theme") == true);
    var neu = new ResourceDictionary
    {
        Source = new Uri($"Themes/{name}.xaml", UriKind.Relative)
    };
    if (old is not null) merged[merged.IndexOf(old)] = neu;   // ← 差し替え
    else                 merged.Add(neu);
}

【DynamicResource が必須である理由】★
   ・StaticResource で参照していると、
     ディクショナリを差し替えても【古い値のまま】
   ・テーマ切り替え対象のリソースは
     【必ず DynamicResource で参照する】

【現在のテーマ対応（.NET 8 以降 / Windows 11）】
   ・OS のライト/ダーク設定を検知する
       SystemParameters / レジストリ / UISettings
   ・WPF 自体はダーク テーマを標準搭載していない
      → 自前で用意するか、ライブラリを使う
         （ModernWpf、MaterialDesignInXamlToolkit、WPF-UI 等）
   ・[Uno Platform](MS_UnoPlatform) / WinUI は
     テーマ切り替えを標準で持つ

様々なソースと「データ バインディング」するサンプルを示す。

なお、サンプルの XAML ソースを読むためには、以下の、
Binding プロパティの設定方法を理解しておく必要がある。

Binding プロパティの設定方法

• Microsoft Learn > ・・・ > バインディングのマークアップ拡張機能
  https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/advanced/binding-markup-extension
  • Microsoft Learn > ・・・ > PropertyPath の XAML 構文
    https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/advanced/propertypath-xaml-syntax
  • Microsoft Learn > ・・・ > 方法：XMLDataProvider と XPath クエリを使用して XML データにバインドする
    https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/data/how-to-bind-to-xml-data-using-an-xmldataprovider-and-xpath-queries

補足（この表に無い、実務で必須の 2 つ）: WPFのアーキテクチャ でも
触れたが、表に挙がっていない重要なプロパティを補っておく。

【UpdateSourceTrigger】★ 本ページ後半で登場する
   いつソースへ書き戻すか
     PropertyChanged / LostFocus / Explicit

【StringFormat】（.NET 3.5 SP1 以降）
   値コンバータを書かずに書式指定できる
     <TextBlock Text="{Binding Price, StringFormat={}{0:N0} 円}" />
     → 【単純な書式なら、コンバータは不要】★

【FallbackValue】
   バインディングが解決できないときの値
   （TargetNullValue は「値が null のとき」で、意味が違う）

【ValidatesOnDataErrors / ValidatesOnNotifyDataErrors】
   IDataErrorInfo / INotifyDataErrorInfo による入力検証

以下、「WPFのアーキテクチャ - データ バインディング」に
対応するサンプルを示す。

• モード：OneWay の「データ バインディング」を行う。

• 「データ バインディング」の基本的な動作を理解するために、

  • Binding オブジェクトをコード ビハインドで自作し、
  • 以下の２つのオブジェクトを結びつける。
    • 「バインディング ソース」
    • 「バインディング ターゲット」

• XAML

<StackPanel 
  x:Name="MainPanel"
  Loaded="MainPanel_Loaded">
  <TextBlock x:Name="TextBlock1"/>
  <TextBlock x:Name="TextBlock2"/>
</StackPanel>

• コード ビハインド

public partial class Window1 : Window {
  public Window1() {
    InitializeComponent();
  }

  private void MainPanel_Loaded(object sender, RoutedEventArgs e)
  {
    // バインディング ソース（Person）
    Person BindingSource =
      new Person() { Height = 1.7, Weight = 60 };

    // Bindingオブジェクトによりバインド

    // HeightプロパティをOneWayでバインド
    Binding BindingHeight = new Binding("Height");
    BindingHeight.Mode = BindingMode.OneWay;
    // バインディング ソース（Person）
    BindingHeight.Source = BindingSource;
    // バインディング ターゲット（TextBlock）
    TextBlock1.SetBinding(TextBlock.TextProperty, BindingHeight);

    // WeightプロパティをOneWayでバインド
    Binding BindingWeight = new Binding("Weight");
    BindingWeight.Mode = BindingMode.OneWay;
    // バインディング ソース（Person）
    BindingWeight.Source = BindingSource;
    // バインディング ターゲット（TextBlock）
    TextBlock2.SetBinding(TextBlock.TextProperty, BindingWeight);
  } 
}

/// <summary>バインディング ソース（Person）</summary>
public class Person {
  public double Height { get; set; }
  public double Weight { get; set; }
}

上記の MainPanel_Loaded メソッドのコードを一部編集し、MainPanel（StackPanel）の
FrameworkElement.DataContext プロパティに「バインディング ソース」を設定することで、
Binding オブジェクトへの「バインディング ソース」の指定が不要になる。

• コード ビハインド

private void MainPanel_Loaded(object sender, RoutedEventArgs e) {
  // バインディング ソース（Person）
  MainPanel.DataContext =
    new Person() { Height = 1.7, Weight = 60 };

  // Bindingオブジェクトによりバインド

  // HeightプロパティをOneWayでバインド
  Binding BindingHeight = new Binding("Height");
  BindingHeight.Mode = BindingMode.OneWay;
  // バインディング ターゲット（TextBlock）
  this.TextBlock1.SetBinding(TextBlock.TextProperty, BindingHeight);

  // WeightプロパティをOneWayでバインド
  Binding BindingWeight = new Binding("Weight");
  BindingWeight.Mode = BindingMode.OneWay;
  // バインディング ターゲット（TextBlock）
  TextBlock2.SetBinding(TextBlock.TextProperty, BindingWeight);
}

• Binding オブジェクトを XAML のマークアップ機能で実装する。
  更に、XAML のマークアップ機能を使用して、
  Binding オブジェクトの生成処理・設定処理を XAML 側に移動することで、
  上記の XAML と MainPanel_Loaded メソッドのコードを一部編集し、
  コード ビハインドのコード量を削減できる。

  • XAML

<StackPanel 
  x:Name="MainPanel"
  Loaded="MainPanel_Loaded">
  <TextBlock>
    <TextBlock.Text>
      <Binding Path="Height" Mode="OneWay"/>
    </TextBlock.Text>
  </TextBlock>
  <TextBlock>
    <TextBlock.Text>
      <Binding Path="Weight" Mode="OneWay"/>
    </TextBlock.Text>
  </TextBlock>
</StackPanel>

• コード ビハインド

private void MainPanel_Loaded
   (object sender, RoutedEventArgs e) {

  // バインディング ソース（Person）
  MainPanel.DataContext =
  new Person() { Height = 1.7, Weight = 60 };
}

• 一般的には、「データ バインディング」を実装する場合、XAML 側の記述は（前述とは異なる）
  「バインディングのマークアップ拡張」により「プロパティ属性構文」化して
  実装する方法を採る。

• 上記の XAML を「バインディングのマークアップ拡張」を使用して、
  「プロパティ属性構文」化して実装すると次のようになる。

<StackPanel x:Name="MainPanel" Loaded="MainPanel_Loaded">
  <TextBlock Text="{Binding Path=Height, Mode=OneWay}" />
  <TextBlock Text="{Binding Path=Weight, Mode=OneWay}" />
</StackPanel>

• また、属性名を省略すると自動的にコンストラクタに渡される動作を利用して、
  （Path 属性に指定の値を渡す旨を指示する）「Path=」という記述を省略することができる。

<StackPanel x:Name="MainPanel" Loaded="MainPanel_Loaded">
  <TextBlock Text="{Binding Height, Mode=OneWay}" />
  <TextBlock Text="{Binding Weight, Mode=OneWay}" />
</StackPanel>

補足（4 段階の書き換えが示すもの）: ここまでの 4 つの例は、
同じ処理を段階的に XAML へ寄せていくという構成になっている。
この流れ自体が WPF の学び方として優れている。

① コードで Binding を作る       … 仕組みが全部見える
② DataContext を使う            … Source の指定が消える
③ XAML の要素構文で書く         … Binding の生成が XAML へ
④ マークアップ拡張で書く         … 1 行になる ★ 実務での書き方

 → 「{Binding Height}」という 1 行が
   何をしているかが分かる

【現在の実務では、さらに先がある】★
   ⑤ DataContext も XAML で設定する
        <Window.DataContext>
          <vm:MainViewModel />
        </Window.DataContext>
      または DI コンテナから注入する

   → コードビハインドが【空になる】＝ MVVM

下記は、モード：OneWay or OneWayToSource を併用した「データ バインディング」による
BMI（肥満度）の自動計算アプリケーションの例である。
この例では、「バインディング ソース」のプロパティ値の変更を、
自動的に「バインディング ターゲット」に反映できる。
なお、この際、「バインディング ソース」は、INotifyPropertyChanged インターフェイスを
実装して、BMI（肥満度）プロパティの変更通知処理を実装する必要がある。

• XAML

<StackPanel x:Name="MainPanel" Loaded="MainPanel_Loaded">
  <TextBox Margin="10" Text="{Binding Height, Mode=OneWayToSource}"/>
  <TextBox Margin="10" Text="{Binding Weight, Mode=OneWayToSource}"/>
  <Button Margin="10" Content="計算" Click="Button_Click" />
  <TextBlock Margin="10" Text="{Binding Bmi, Mode=OneWay}"/>
</StackPanel>

• コード ビハインド

/// <summary>/// Window1.xaml の相互作用ロジック/// </summary>
public partial class Window1 : Window {
  public Window1() {
    InitializeComponent();
  }

  /// <summary>初期化イベント</summary>
  private void MainPanel_Loaded(object sender, RoutedEventArgs e) {
    // バインド ソース（Person）
    MainPanel.DataContext = new Person();
  }
  /// <summary>計算イベント</summary>
  private void Button_Click(object sender, RoutedEventArgs e) {
    ((Person)MainPanel.DataContext).Calculate();
  } 
}

• バインディングソース

/// <summary>バインド ソース（Person）</summary>
public class Person : INotifyPropertyChanged {
  public double Height { get; set; }
  public double Weight { get; set; }

  double _bmi;
  public double Bmi {
    get { return this._bmi; }
    set {
      this._bmi = value;

      // 変更通知
      this.OnPropertyChanged("Bmi");
    }
  }

  /// <summary>計算処理</summary>
  public void Calculate() {
    this.Bmi = Weight / Math.Pow(Height, 2);
  }

  #region INotifyPropertyChanged メンバ

  /// <summary>値変更イベントの定義</summary>
  public event PropertyChangedEventHandler PropertyChanged;

  /// <summary>変更通知（値変更イベントを発生させる）</summary>
  protected virtual void OnPropertyChanged(string propertyName) {
    PropertyChangedEventHandler handler = this.PropertyChanged;

    if (handler != null)
      handler(this, new PropertyChangedEventArgs(propertyName));
  }

  #endregion
}

補足（現在の書き方 ── 文字列指定をなくす）: OnPropertyChanged("Bmi") の
文字列指定は、リファクタリング時に壊れる。
現在は 2 段階で改善されている。

// ① CallerMemberName（.NET 4.5 以降）★ 文字列を書かない
protected void OnPropertyChanged([CallerMemberName] string? name = null)
    => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));

public double Bmi
{
    get => _bmi;
    set { _bmi = value; OnPropertyChanged(); }   // ← 引数なしで呼べる
}

// ② Source Generator（.NET Community Toolkit）★ 定型コードごとなくす
public partial class Person : ObservableObject
{
    [ObservableProperty] private double _height;
    [ObservableProperty] private double _weight;
    [ObservableProperty] private double _bmi;

    [RelayCommand]
    private void Calculate() => Bmi = Weight / Math.Pow(Height, 2);
}

【このサンプルの設計上の問題】★
 ・Height / Weight が【変更通知を持たない】自動プロパティ
    → OneWayToSource なので画面→モデルは動くが、
      モデル→画面には反映されない（このサンプルでは不要）
 ・「計算」ボタンのクリックを【コードビハインドで拾っている】
    → MVVM では ICommand（RelayCommand）を使う
 ・Height が 0 のとき【ゼロ除算】になる
    → double なので例外にはならず、Infinity / NaN が表示される
    → [数値の計算方法](MS_NumericCalculation) 参照

続いて、上記処理に、BMI（肥満度）プロパティが

• 18.5 未満の場合、出力先の TextBlock の背景色を青色に
• 25 以上の場合、出力先の TextBlock の背景色を赤色に

変更する処理を追加する。

これには別途、背景色プロパティを定義することで実現することも可能であるが、
ここでは、前述の IValueConverter インターフェイスを実装した「値コンバータ」を
実装することでこれを実現する。
値の変換処理は、「値コンバータ」の Convert メソッドに実装する。

• XAML

<Window.Resources>
  <my:BmiLevelConverter x:Key="bmiLevelConverter"/>
</Window.Resources>
<StackPanel x:Name="MainPanel" Loaded="MainPanel_Loaded">
  <TextBox Margin="10" Text="{Binding Height, Mode=OneWayToSource}"/>
  <TextBox Margin="10" Text="{Binding Weight, Mode=OneWayToSource}"/>
  <Button Margin="10" Content="計算" Click="Button_Click" />
  <TextBlock Margin="10"
    Text="{Binding Bmi, Mode=OneWay}"
    Background="{Binding Bmi, Mode=OneWay,
    Converter={StaticResource bmiLevelConverter}}"/>
</StackPanel>

• 値コンバータ

/// <summary>BMIレベルに合った背景色を返す</summary>
public class BmiLevelConverter : IValueConverter {
  #region IValueConverter メンバ

  /// <summary>変換メソッド（ソースからターゲット）</summary>
  public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture) {
    // BMIレベルに合った背景色を返す
    double target = (double)value;
    SolidColorBrush level;

    if (target < 18.5)
      level = new SolidColorBrush(Colors.Blue);
    else if (target > 25)
      level = new SolidColorBrush(Colors.Red);
    else
      level = new SolidColorBrush(Colors.White);

    return level;
  }

  /// <summary>変換メソッド（ターゲットからソース）</summary>
  public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture) {
    throw new NotImplementedException();
  }

  #endregion
}

補足（値コンバータ vs トリガー）: このような
「値に応じて見た目を変える」処理には、後述の DataTrigger でも実装できる。
使い分けを整理しておく。

	値コンバータ	DataTrigger
記述場所	C# コード	XAML
条件	任意のロジック（範囲判定、計算）	等値比較のみ ★
再利用	複数箇所で使える	スタイルとして使える
テスト	単体テストが書ける ★	書けない

【このサンプルの場合】
   「18.5 未満」「25 以上」という【範囲判定】なので、
   DataTrigger（等値比較）では書けない
   → 【値コンバータが適切】★

【DataTrigger が適する例】
   IsSelected="True" のとき背景を変える、等

【この実装の改善点】
 ① Brush を毎回 new している
      → 【Brushes.Blue 等の静的インスタンスを使う】（軽い・Freeze 済み）
 ② 25 ちょうどが「白」になる（> 25 のため）
      → 仕様として意図的かどうか確認が要る
 ③ ConvertBack が NotImplementedException
      → OneWay 専用なら Binding.DoNothing を返す方が安全
 ④ 【色を直接返している】
      → テーマ対応を考えるなら「状態（enum）」を返し、
        色は DataTrigger / スタイル側で決める設計もある

なお、変更通知は、INotifyPropertyChanged インターフェイスの実装ではなく、
「依存関係プロパティ」でも代替できる。
上記の例の BMI（肥満度）プロパティを「依存関係プロパティ」として、
以下のように書き直し、動作を確認する。

• バインディングソース

/// <summary>バインド ソース（Person）</summary>
public class Person : DependencyObject {
  public double Height { get; set; }
  public double Weight { get; set; }

  /// <summary>Bmiプロパティを依存関係プロパティとして登録</summary>
  public static readonly DependencyProperty BmiProperty =
    DependencyProperty.Register("Bmi", typeof(double), typeof(Person), 
        new UIPropertyMetadata(0.0));

  /// <summary>BmiプロパティのCLRプロパティ</summary>
  public double Bmi {
    get { return (double)this.GetValue(Person.BmiProperty); }
    set { this.SetValue(Person.BmiProperty, value); }
  }

  /// <summary>計算処理</summary>
  public void Calculate(){
    this.Bmi = Weight / Math.Pow(Height, 2);
  }
}

BMI（肥満度）プロパティが変更されると、UI 要素（TextBlock）に変更が反映されることを
確認できる。
このように、「依存関係プロパティ」は既定で変更通知をサポートしている。

補足（技術的には可能だが、モデル側では使わない）: この節の内容は
「できる」ことの確認としては正しいが、
実務でモデル／ViewModel を DependencyObject にすることは推奨されない。

【DependencyObject にする欠点】★
 ① 【UI スレッド アフィニティを持つ】
      → 別スレッドから値を設定すると【例外】
      → [Control.Invoke、.BeginInvoke](MS_ControlInvoke) と同じ制約
      → 非同期でデータを取得する ViewModel では致命的
 ② WindowsBase.dll（WPF）に【依存する】
      → ViewModel を他の UI 基盤（MAUI、Blazor）と共有できない
      → 単体テストで WPF の参照が要る
 ③ 依存関係プロパティは【重い】（登録・辞書アクセス）
 ④ シリアライズしにくい

【したがって】
   ・View 側（コントロール）→ 【依存関係プロパティ】★
   ・Model / ViewModel 側   → 【INotifyPropertyChanged】★

 → [WPFのコントロール](MS_WPFControls) の
   「バインディング ソース」と「バインディング ターゲット」の
   区別がここでも効く

移行メモ（UIPropertyMetadata）: サンプルが使っている
UIPropertyMetadata は現在は使われない
（PropertyMetadata または FrameworkPropertyMetadata を使う）。
動作はするが、追加の機能は持たない。

以下の例では、モード：TwoWay の「データ バインディング」を行うため、
2 つの UI 要素、TextBox と Slider を双方向接続した例である。

なお前述のように UI 要素の表示に関するプロパティは、
基本的に「依存関係プロパティ」として定義されており、
既定で変更通知をサポートしている。このため、既定で双方向接続が可能である。

なお、「バインディング ソース」を UI 要素に接続する場合は、
ElementName 属性を使用すると良い。

• TextBox（ソース）→ Slider（ターゲット）

  • XAML

<StackPanel Orientation="Vertical">
  <Label>TextBox</Label>
  <TextBox x:Name="textBox1" Text="5"/>
  <Rectangle Height="20"></Rectangle>
  <Label>Slider</Label>
  <Slider x:Name="Slider1" 
    Value="{Binding ElementName=textBox1, Path=Text, Mode=TwoWay}"/>
</StackPanel>

• Slider（ソース）→ TextBox（ターゲット）

  • バインディング ソース、バインディング ターゲットを反転する。

  • すると「バインディング ターゲット」（TextBox）の変更が直ちに通知されなくなる。
    （TextBox から、フォーカスが外れないと Slider に変更値が反映されない）。

  • これは、ほとんどの依存関係プロパティの既定値は PropertyChanged であるが、
    Text プロパティの既定値は LostFocus のため。

  • この場合、「バインディングのマークアップ拡張」に、
    「UpdateSourceTrigger=PropertyChanged」という属性の記述を追加することで、
    「バインディング ターゲット」（TextBox）からの変更が直ちに
    「バインディング ソース」（Slider）に通知されるようになる。

  • XAML

<StackPanel Orientation="Vertical">
  <Label>TextBox</Label>
  <TextBox x:Name="textBox1"
    Text="{Binding ElementName=Slider1, Path=Value, Mode=TwoWay}"/>
  <Rectangle Height="20"></Rectangle>
  <Label>Slider</Label>
  <Slider x:Name="Slider1" Value="5"/>
</StackPanel>

• Microsoft Learn > .NET Framework クラス ライブラリ > System.Windows.Data.Binding
  • UpdateSourceTrigger プロパティ
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.data.binding.updatesourcetrigger
  • UpdateSourceTrigger 列挙体
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.data.updatesourcetrigger

補足（UpdateSourceTrigger の指摘は実務で最重要）: この節が指摘する
**「TextBox.Text だけ既定が LostFocus」**という点は、
WPF で最も多く踏まれる罠である。

【なぜ TextBox.Text だけ違うのか】
   ・入力の途中で毎回ソースに書き戻すと、
     「1」→「12」→「123」と入力する間に
     【中途半端な値がモデルに入る】
   ・検証エラーが 1 文字ごとに出る
     → だから【確定（フォーカス喪失）時】を既定にした

【PropertyChanged にすべき場面】★
   ・スライダーとの連動（このサンプル）
   ・インクリメンタル検索
   ・入力しながらプレビューを更新する

【LostFocus のままがよい場面】
   ・数値入力（途中の値が不正になる）
   ・検証を伴う入力

【MVVM での注意】★
   「入力したのに ViewModel の値が変わらない」
     → LostFocus のまま、かつボタンを
       【マウスではなくショートカットで押した】
     → フォーカスが移らないので書き戻されない
     → UpdateSourceTrigger=PropertyChanged にするか、
       ボタンに Focusable な操作を挟む

ElementName バインディングの位置付け:

・【View 内で完結する連動】には便利（このサンプル）
・ただし MVVM では【使いすぎない】
   → 画面内の状態が ViewModel に現れなくなる
   → テストできない
・「表示上の連動」ならよい、
  「業務的な意味のある値」なら ViewModel を経由させる

双方向の値の変換に対応した「値コンバータ」は、
Convert、ConvertBack メソッドの双方を実装する必要がある。

• XAML

<Window.Resources>
  <my:ValConverter x:Key="valConverter" />
</Window.Resources>
<StackPanel Orientation="Vertical">
  <Label>TextBox</Label>
  <TextBox x:Name="textBox1" Text="500"/>
  <Rectangle Height="20"></Rectangle>
  <Label>Slider</Label>
  <Slider x:Name="Slider1"
    Value="{Binding ElementName=textBox1, Path=Text, Mode=TwoWay,
    Converter={StaticResource valConverter}}"/>
</StackPanel>

• コード ビハインド

public class ValConverter : IValueConverter {
  #region IValueConverter メンバ

  /// <summary>変換メソッド（ソースからターゲット）</summary>
  public object Convert(object value, Type targetType,
    object parameter, System.Globalization.CultureInfo culture) {
    return int.Parse(value.ToString()) / 100;
  }

  /// <summary>変換メソッド（ターゲットからソース）</summary>
  public object ConvertBack(object value, Type targetType,
    object parameter, System.Globalization.CultureInfo culture) {
    return ((double)value) * 100;
  }

  #endregion
}

補足（この実装の注意点）: 動作としては正しいが、
本番コードでは以下を補う必要がある。

// ① int の除算になっている ★
return int.Parse(value.ToString()) / 100;
//     500 / 100 = 5（整数除算）
//     450 / 100 = 4（4.5 にならない）
//  → double で計算する
return double.Parse(value.ToString(), culture) / 100.0;

// ② culture を無視している
//    小数点が "," の文化圏では Parse が失敗する
//  → 引数の culture を使う（[カルチャ](MS_Culture) 参照）

// ③ 数値以外が入力されると FormatException
//  → TryParse にし、失敗時は DependencyProperty.UnsetValue を返す

public object Convert(object value, Type t, object p, CultureInfo c)
    => double.TryParse(value?.ToString(), NumberStyles.Any, c, out var d)
         ? d / 100.0
         : DependencyProperty.UnsetValue;      // ← 変換できないことを伝える ★

ItemsControl から派生した要素の ItemsSource 属性にコレクションを
「データ バインディング」する場合、対象オブジェクトは反復処理をサポートしている
必要がある。

• ItemsSource へのデータ バインディング（UI 要素を含まない「データ バインディング」）
  以下は、ObservableCollection<T> コレクション クラスを使用して
  「データ バインディング」する例である。
  なお、ObservableCollection<T> コレクション クラスは、
  INotifyPropertyChanged インターフェイスを継承しており、変更通知が可能となっている。

  • XAML

<StackPanel x:Name="stackPanel1">
  <ListBox x:Name="listBox1" ItemsSource="{Binding}"/>
  <Button Height="23" Name="button1" Click="button1_Click">Button</Button>
</StackPanel>

• コード ビハインド

public partial class Window1 : Window {

  ObservableCollection<string> _cities = new ObservableCollection<string>();

  public Window1() {
    InitializeComponent();

    this._cities.Add("札幌市");
    this._cities.Add("仙台市");
    this._cities.Add("静岡市");

    this.stackPanel1.DataContext = _cities;
  }

  private void button1_Click(object sender, RoutedEventArgs e) {
    this._cities.Add("神戸市" + this.listBox1.Items.Count.ToString());
  }
}

• UI 要素を含まない「データ バインディング」の実装例について、
  • 上記例では、button1_Click イベントで Item が ObservableCollection<T>
    コレクションに追加さると直ちに ListBox の表示に反映されることが確認できる。
    また、この変更通知をサポートしている ObservableCollection<T>
    コレクション クラスを、変更通知をサポートしない Collection<T>
    コレクション クラスに変更した場合、
    Collection<T> コレクションに追加された Item が
    ListBox の表示に反映されないことも確認できる。
  • なお、変更通知に対応したカスタム コレクションを作成する場合は、
    ObservableCollection<T> や、
    Collection<T> & INotifyCollectionChanged を継承した
    カスタム コレクションを作成すると良い。
  • この際の注意点としては、後者の Collection<T> & INotifyCollectionChanged を
    継承したカスタム コレクションを作成する場合、
    Add、RemoveAt などのメソッドに変更通知を実装し、
    「変更通知の基盤処理」の値変更イベントに、
    前述の PropertyChangedEventHandler ではなく、
    NotifyCollectionChangedEventHandler を使用する点である。

移行メモ（ObservableCollection<T> が継承するインターフェイス）: 原文は
「INotifyPropertyChanged インターフェイスを継承しており」と
書いているが、コレクションの変更（追加・削除）を通知するのは
INotifyCollectionChanged である。

【ObservableCollection<T> が実装するもの】
   ・INotifyCollectionChanged ★ 【追加・削除・移動】を通知
   ・INotifyPropertyChanged      Count / Item[] の変更を通知

 → 【両方】実装している
 → ListBox の表示が更新されるのは
   【INotifyCollectionChanged のおかげ】である

原文自身が 3 つ目の項目で
**「NotifyCollectionChangedEventHandler を使用する点である」**と
正しく述べているため、最初の記述が言い落としたものと読める。

• ItemsSource へのデータ バインディング（UI 要素を含んだ「データ バインディング」）
  以下は、「Items プロパティ」の例を「データ バインディング」で実装した例である。

  • XAML

<StackPanel x:Name="stackPanel1">
  <ListBox ItemsSource="{Binding}"/>
</StackPanel>

• コード ビハインド

public Window1() {
  InitializeComponent();

  // バンディング ソース（コレクション）
  ObservableCollection<Border> cities = new ObservableCollection<Border>();

  // ワーク
  Border tmpBorder = null;
  StackPanel tmpStackPanel = null;
  Image tmpImage = null;
  TextBlock tmpTextBlock = null;

  // Borderの構築
  tmpBorder = new Border();
  tmpBorder.BorderBrush = Brushes.Black;
  tmpBorder.BorderThickness = new Thickness(1);
  tmpBorder.Margin = new Thickness(5);

  // StackPanelの構築
  tmpStackPanel = new StackPanel();
  tmpStackPanel.Orientation = Orientation.Horizontal;
  tmpStackPanel.Height = 120;
  tmpStackPanel.Width = 250;
  tmpStackPanel.Margin = new Thickness(5);

  // Imageの構築
  tmpImage = new Image();
  tmpImage.Source=new BitmapImage(
    new Uri(@".\Water lilies.jpg", UriKind.Relative));
  tmpImage.Height=100;

  // TextBlockの構築
  tmpTextBlock = new TextBlock();
  tmpTextBlock.Text="Water lilies";
  tmpTextBlock.VerticalAlignment = VerticalAlignment.Center;

  // 階層構造の組み立て
  tmpStackPanel.Children.Add(tmpImage);
  tmpStackPanel.Children.Add(tmpTextBlock);

  tmpBorder.Child = tmpStackPanel;

  // バンディング ソース（コレクション）に追加
  cities.Add(tmpBorder);

  // ・・・（ｎ項繰り返し）・・・

  // データ バンディング
  stackPanel1.DataContext = cities;
}

• UI 要素を含んだ「データ バインディング」の実装例について、
  • 子要素を持つ UI 要素をコード ビハインドで作成し、
    これを「データ バインディング」する実装例も、一般的ではない。
  • このような場合は、「テンプレート」を使用するのが一般的である。
  • 「テンプレート」を使用した実装例は、
    「スタイルとテンプレート」 - 「テンプレート」を参照のこと。

補足（原文の「一般的ではない」という自己評価は正しい）: この実装は
意図的に「やってはいけない例」として示されていると読める。
問題点を明示しておく。

【UI 要素をコレクションに入れる問題】★
 ① 【データと表示が分離できない】
      → MVVM の前提が崩れる
      → ViewModel が WPF に依存する
 ② 【仮想化が効かない】
      → 1 万件なら 1 万個の UI 要素が生成される
      → メモリと初期化時間が爆発する
 ③ UI 要素は【1 つの親にしか属せない】
      → 同じ Border を 2 箇所で使えない
 ④ 別スレッドで生成できない（UI スレッド アフィニティ）
 ⑤ 単体テストが書けない

【正しい方法】
   データ（POCO）のコレクションをバインドし、
   見た目は【DataTemplate で 1 回だけ定義する】★
   → 次節「スタイルとテンプレート」で示される

インデクサについても、Path 属性に角括弧を指定することで接続可能である。

• XAML

<Grid>
  <Image x:Name="Image1"
    Height="200" Width="200"
    Source="{Binding Path=[Source]}"
    ToolTip="{Binding Path=[ToolTip]}"/>
</Grid>

• コード ビハインド

public Window1() {
  InitializeComponent();

  Hashtable ht = new Hashtable();
  ht["Source"] = @".\Winter.jpg";
  ht["ToolTip"] = "Winter";
  this.Image1.DataContext = ht;
}

これらを応用すると、

インデクサを持つオブジェクトの配列（反復処理をサポート）
をデータ バインディングすることも可能であることが分かる。

ビジネス・アプリケーションでは、DataGrid へ DataTable をデータ バインディングする際に、
DataGrid の列へ DataTable の列をマッピングするようなケースでよく利用します。

補足（インデクサ バインディングの実務での位置付け）: 原文が最後に
述べている通り、DataTable との連携が主用途である
（WPFのアーキテクチャ にも記した）。

<!-- DataTable の列を DataGrid の列にマッピングする -->
<DataGridTextColumn Header="名前" Binding="{Binding [Name]}" />

【注意点】★
 ・【型が分からない】ため、コンパイル時に検証されない
    → 列名の打ち間違いは実行時まで分からない
    → [ASP.NET MVCでDataTableを使用する。](MS_ASPNETMVCDataTable) の
      「DataTable の欠点」と同じ問題
 ・Hashtable / Dictionary は【変更通知を持たない】
    → 値を変えても画面に反映されない
    → ObservableDictionary 等を自作するか、POCO にする

【インデクサ バインディングの正しい使いどころ】
   ・列が【実行時にしか決まらない】画面（汎用検索、帳票定義）
   ・それ以外は【POCO にして型を効かせる】★

「リソース」参照を「バインディングのマークアップ拡張」でも使用することができる。

• 例えば、静的な「リソース」を使用し、以下のように「データ バインディング」できる。

  • StaticResource のデータ バインディング (1)

<Window.Resources>
  <sys:String x:Key="val">Click Here</sys:String >
</Window.Resources>
<StackPanel>
  <Button Content="{Binding Source={StaticResource val}}"/>
</StackPanel>

※ 先頭で、String 型のインポートが必要
xmlns:sys="clr-namespace:System;assembly=mscorlib"

• ItemsControl から派生した UI コントロールの ItemsSource 属性に
  「データ バインディング」する場合、
  「リソース」の対象オブジェクトは反復処理をサポートしている必要がある。

  • StaticResource のデータ バインディング (2)

<Window.Resources>
  <x:Array x:Key="list"
    Type="{x:Type sys:String}">
    <sys:String>A</sys:String>
    <sys:String>B</sys:String>
    <sys:String>C</sys:String>
  </x:Array>
</Window.Resources>
<StackPanel>
  <ListBox ItemsSource="{Binding Source={StaticResource list}}"/>
</StackPanel>

※ 先頭で、String 型のインポートが必要
xmlns:sys="clr-namespace:System;assembly=mscorlib"

動的な「リソース」を使用した「データ バインディング」はサポートされない。
以下、「{Binding Source={DynamicResource」をテストした際のエラーメッセージである。

型 'Binding' の 'Source' プロパティで 'DynamicResourceExtension' を設定することはできません。'DynamicResourceExtension' は、DependencyObject の DependencyProperty でのみ設定できます。

• 参考
  • Microsoft Learn > .NET Framework クラス ライブラリ
    • System.Windows.Data.Binding.Source プロパティ
      https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.data.binding.source
    • System.Windows.DynamicResourceExtension クラス
      https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.dynamicresourceextension

補足（このエラーの理由と、回避策）: 実際に試してエラー メッセージまで
記録している点が有用なので、理由を補っておく。

【なぜ Binding.Source に DynamicResource が使えないのか】★
   ・DynamicResource は【依存関係プロパティにしか設定できない】
   ・Binding クラスは DependencyObject では【ない】
      → Binding.Source は【ただの CLR プロパティ】
      → だから設定できない

 → [WPFのアーキテクチャ](MS_WPFArchitecture) の
   「依存関係プロパティ」の制約がそのまま現れている

【回避策】
 ① そもそも Binding を挟まない
      <Button Content="{DynamicResource val}" />
      → 【Content は依存関係プロパティなので設定できる】★
      → 多くの場合、これで足りる

 ② 値の変更を追いたいなら、
    ViewModel のプロパティにして INotifyPropertyChanged で通知する

 ③ 【リソースを ViewModel 経由にする】
    → テーマ切り替えなら、DynamicResource を直接使う（①）

ココでは、レイアウト方法として、

• レイアウトのプロパティ
• パネルの種類と使い方

の 2 つについて説明する。

• Microsoft Learn > WPF の基礎 > レイアウト システム
  https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/advanced/layout

• ココでは、「レイアウト」関係のプロパティについて説明する。

• これらのプロパティは、「レイアウト」機能を追加する FrameworkElement 基本クラスにより
  提供される。

  • 配置の際、各要素間に余白を指定したい場合は、Margin、Padding 属性を使用する。
    • Margin ：自要素と親要素の間
    • Padding：自要素と子要素の間
      ※ [left, top, right, bottom] と設定可能。省略時の動作は、リファレンスを参照のこと。
  • 配置の際、「揃え」を指定したい場合は、
    HorizontalAlignment、VerticalAlignment 属性を使用する。
    • HorizontalAlignment ：水平方法の揃え（Center、Left、Right、Stretch を指定可）
    • VerticalAlignment ：垂直方法の揃え（Center、Top、Bottom、Stretch を指定可）
      ※ Stretch は、引き伸ばして余白を埋めて配置の意味。

• 以下、「レイアウト」関係のプロパティを使用した XAML とレンダリングの例を示す。

  • XAML

<Border Background="LightBlue" BorderBrush="Black" BorderThickness="2" Padding="15">
  <StackPanel Background="White" HorizontalAlignment="Center" VerticalAlignment="Top">
    <TextBlock Margin="5,0,5,0" HorizontalAlignment="Center">Alignment, Margin and Padding Sample</TextBlock>
    <Button HorizontalAlignment="Left" Margin="20">Button 1</Button>
    <Button HorizontalAlignment="Right" Margin="10">Button 2</Button>
    <Button HorizontalAlignment="Stretch" Margin="0">Button 3</Button>
  </StackPanel>
</Border>

• レンダリング（Microsoft Learn 掲載の図）

• 参考

  • Microsoft Learn > WPF の基礎 > 基本要素 > 配置、余白、パディングの概要
    https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/advanced/alignment-margins-and-padding-overview

移行メモ（レンダリング結果の図）: 本節の「レンダリング」は、
移行元でも MSDN 上の画像を直接参照していた（添付ファイルではない）。
当該 URL（i-msdn.sec.s-msft.com 配下）は
現在は解決しないため、参照先を Microsoft Learn の該当ページに変更した。

補足（Margin と Padding の使い分け）: 説明は正確だが、
Padding を持つ要素は限られる点を補っておく。

【Margin】
   FrameworkElement が持つ ＝ 【ほぼ全要素にある】★

【Padding】
   Control、Border、TextBlock など【一部の型にしかない】
     → StackPanel、Grid には Padding が【ない】
     → 内側に余白が欲しければ Border で包む

【Margin の指定方法】
   Margin="10"              … 上下左右すべて 10
   Margin="10,20"           … 左右 10、上下 20
   Margin="10,20,30,40"     … 左 10、上 20、右 30、下 40 ★

 → 【左・上・右・下】の順（CSS の「上右下左」とは違う）

【Margin の相殺は起きない】★
   CSS では隣接する margin が相殺される（margin collapse）が、
   WPF では【相殺されない】
     → 上下に Margin="10" の要素を並べると、間隔は 20 になる
     → CSS の感覚で書くと間延びする

Stretch が既定である点も重要である。

【HorizontalAlignment / VerticalAlignment の既定は Stretch】
   → Width / Height を指定しない要素は【親いっぱいに広がる】
   → 「なぜかボタンが横幅いっぱいになる」の理由
   → Left / Center 等を明示するか、Width を指定する

WPF では、パネルを使用した「レイアウト」が可能である。

• パネルには、以下のような特徴がある。

  • 複数の UIElement を含めることができる（UIElementCollection のプロパティを持つ）。

    • Microsoft Learn > .NET Framework クラス ライブラリ >
      System.Windows.Controls.UIElementCollection クラス
      https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.controls.uielementcollection

      UIElement 子要素の順序付けられたコレクションを表す。
      XAML から「プロパティ要素構文」の「コンテンツ構文」でパネル要素に
      子要素を追加する場合は、
      <Panel.Children> タグを使用する
      （ただし、このタグを明示しなくとも、暗黙的に使用される）。
      また、コード ビハインドから、パネル要素に子要素を追加する場合は、
      Children.Add メソッドを使用する。

  • 自分に含まれる UIElement を管理する。

  • パネル自体も UIElement であるため、パネルへの組み込みが可能

• 使用可能なパネル要素には次のものがある。

• また、親要素であるパネルへ配置する子要素の座標などの情報については、
  子要素から「添付プロパティ」を使用して設定可能である。

補足（表に無いパネル）: 6 種類は主要なものだが、
実務でよく使う 2 つを補っておく。

パネル	用途
VirtualizingStackPanel	仮想化する StackPanel。ItemsControl の既定 ★
ItemsPanel（各 ItemsControl）	後述の ItemsPanelTemplate で差し替えられる

【仮想化が最重要】★
   ・ListBox の既定の ItemsPanel は VirtualizingStackPanel
      → 【画面に見えている項目だけ】UI 要素を作る
      → 1 万件でも軽い

   ・【仮想化が無効になる書き方】
      ① ItemsPanel を StackPanel に変更する
      ② ScrollViewer で ListBox を包む
          → ListBox が「高さ無限」と判断し、全項目を作る
      ③ ListBox の Height を指定しない状況で
         StackPanel の中に置く                     ← 最頻出 ★

   → 「件数が増えると固まる」の原因はほぼこれ

• 座標を使用して子要素を明示的に配置できる領域を定義する。
  • XAML

<Canvas Background="LightSteelBlue">
  <TextBlock Canvas.Top="10" Canvas.Left="20">
    Hello World!
  </TextBlock>
  <TextBlock Canvas.Top="40" Canvas.Left="50">
    絶対位置決め方式は便利ではありませんか？
  </TextBlock>
</Canvas>

• レンダリング結果

• キャンバス パネルでは、「添付プロパティ」である Canvas.Top・Canvas.Left 属性を使用して、
  子要素から座標位置を明示的に指定・配置できるため、
  Windows フォームに近い開発が可能である。

• 参考

  • Microsoft Learn > .NET Framework クラス ライブラリ >
    System.Windows.Controls.Canvas クラス
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.controls.canvas

補足（「Windows フォームに近い開発が可能」への注意）: 原文の指摘は
事実だが、Canvas を業務画面のレイアウトに使うのは推奨されない。

【Canvas の問題】★
 ・【可変長のレイアウトができない】
    → ウィンドウのサイズ変更に追随しない
    → 文字サイズ・DPI が変わると崩れる
    → 【多言語化で文字列が伸びると重なる】
      （[国際化対応項目](MS_InternationalizationItems)）
 ・Measure/Arrange の交渉が働かない（子は無限サイズと判断する）
 ・保守時に「1px ずらす」作業が発生する

【Canvas が適する場面】
 ・図形の描画（グラフ、図面、ゲーム）★
 ・座標が本質的に意味を持つもの
 ・ドラッグで自由配置する UI

【Windows Forms からの移行で陥りやすい】
   「デザイナで座標を置く」感覚のまま Canvas を使うと、
   WPF の利点（可変レイアウト・DPI 非依存）を全部捨てることになる ★
   → Grid + StackPanel で組み直す方がよい

Canvas.ZIndex も添付プロパティとして用意されており、
重なり順を制御できる（既定は記述順）。

• パネルの各「辺」に、子要素をドッキングする領域を定義する。
  • XAML

<DockPanel LastChildFill="True">
  <Border Height="25" Background="SkyBlue" DockPanel.Dock="Top">
    <TextBlock Foreground="Black">Dock = "Top（１）"</TextBlock>
  </Border>
  <Border Height="25" Background="SkyBlue" DockPanel.Dock="Top">
    <TextBlock Foreground="Black">Dock = "Top（２）"</TextBlock>
  </Border>
  <Border Height="25" Background="LemonChiffon" DockPanel.Dock="Bottom">
    <TextBlock Foreground="Black">Dock = "Bottom"</TextBlock>
  </Border>
  <Border Width="100" Background="PaleGreen" DockPanel.Dock="Left">
    <TextBlock Foreground="Black">Dock = "Left"</TextBlock>
  </Border>
  <Border Background="White">
    <TextBlock Foreground="Black">
      This content will "Fill" the remaining space
    </TextBlock>
  </Border>
</DockPanel>

• レンダリング結果

• DockPanel.LastChildFill プロパティ（LastChildFill 属性）を true（既定値）に設定すると、
  DockPanel の最終の子要素は常に残りの領域を埋めるようになる。

• 参考

  • Microsoft Learn > .NET Framework クラス ライブラリ >
    System.Windows.Controls.DockPanel クラス
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.controls.dockpanel

補足（DockPanel は「記述順」が意味を持つ）: 図を見ると分かるが、
同じ Dock でも、書いた順に領域が削られていく。

【この例の場合】
   ① Top（１）  … 上端 25px を取る
   ② Top（２）  … 【残りの】上端 25px を取る
   ③ Bottom     … 残りの下端 25px を取る
   ④ Left       … 残りの左端 100px を取る
   ⑤ （最後）   … LastChildFill=True なので残り全部

 → 【順序を入れ替えると結果が変わる】★
   「Left を先に書くと、上端まで Left が伸びる」

【実務での使いどころ】
   アプリの基本レイアウト（メニュー・ツールバー・ステータスバー）
     <DockPanel>
       <Menu DockPanel.Dock="Top" />
       <ToolBar DockPanel.Dock="Top" />
       <StatusBar DockPanel.Dock="Bottom" />
       <Grid>本体</Grid>            ← LastChildFill で残り全部
     </DockPanel>

 → Grid でも書けるが、【DockPanel の方が意図が明確】★

• 子要素を水平方向または垂直方向に整列する領域を定義する。
  • XAML
    • 水平方向

<StackPanel Orientation="Horizontal">
  <RadioButton Margin="4">test1</RadioButton>
  <RadioButton Margin="4">test2</RadioButton>
  <RadioButton Margin="4">test3</RadioButton>
</StackPanel>

- 垂直方向

<StackPanel Orientation="Vertical">
  <RadioButton Margin="4">test1</RadioButton>
  <RadioButton Margin="4">test2</RadioButton>
  <RadioButton Margin="4">test3</RadioButton>
</StackPanel>

• レンダリング結果
  • 水平方向

- 垂直方向

• 整列方向は、StackPanel.Orientation プロパティ（Orientation 属性）で指定する。

• 参考

  • Microsoft Learn > .NET Framework クラス ライブラリ >
    System.Windows.Controls.StackPanel クラス
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.controls.stackpanel

補足（StackPanel の最大の落とし穴）: 最も手軽なパネルだが、
性能問題の原因になりやすい。

【StackPanel は積む方向に「無限の長さ」を与える】★

   Orientation="Vertical" の場合、
   子に渡す availableSize.Height = ∞
     → 子は「好きなだけ高くなってよい」と判断する

【帰結】
 ① 子の ListBox / DataGrid が【仮想化しなくなる】★
      → 全項目を実体化する → 固まる
 ② 子の Height="Auto" が効かない（常に必要なだけ伸びる）
 ③ ScrollViewer に入れないと、はみ出した分が見えなくなる

【対策】
   ・「残りを埋める」レイアウトには【Grid を使う】
       <Grid>
         <Grid.RowDefinitions>
           <RowDefinition Height="Auto" />
           <RowDefinition Height="*" />     ← ここに ListBox
         </Grid.RowDefinitions>
       </Grid>
   ・StackPanel は【中身のサイズが小さいと分かっている場合】に使う

• 子要素を水平方向または垂直方向に整列し、端に達したら改行して整列する領域を定義する。
  ※ パネルのサイズが変更されると、改行位置も変更される。
  • XAML
    • 水平方向

<WrapPanel Orientation="Horizontal">            
  <Button Width="26" Height="26" Margin="4" Content="0"></Button>
  <Button Width="26" Height="26" Margin="4" Content="1"></Button>
  <Button Width="26" Height="26" Margin="4" Content="2"></Button>
　・・・
  <Button Width="26" Height="26" Margin="4" Content="7"></Button>
  <Button Width="26" Height="26" Margin="4" Content="8"></Button>
  <Button Width="26" Height="26" Margin="4" Content="9"></Button>
</WrapPanel>

- 垂直方向

<WrapPanel Orientation="Vertical">            
  <Button Width="26" Height="26" Margin="4" Content="0"></Button>
  <Button Width="26" Height="26" Margin="4" Content="1"></Button>
  <Button Width="26" Height="26" Margin="4" Content="2"></Button>
　・・・
  <Button Width="26" Height="26" Margin="4" Content="7"></Button>
  <Button Width="26" Height="26" Margin="4" Content="8"></Button>
  <Button Width="26" Height="26" Margin="4" Content="9"></Button>
</WrapPanel>

• レンダリング結果
  • 水平方向

- 垂直方向

• 整列方向は、WrapPanel.Orientation プロパティ（Orientation 属性）で指定する。

• 参考

  • Microsoft Learn > .NET Framework クラス ライブラリ >
    System.Windows.Controls.WrapPanel クラス
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.controls.wrappanel

補足（WrapPanel は仮想化されない）: 便利だが、
VirtualizingWrapPanel は標準にない点に注意する。

【ItemsPanel を WrapPanel にすると】
   <ListBox>
     <ListBox.ItemsPanel>
       <ItemsPanelTemplate><WrapPanel /></ItemsPanelTemplate>
     </ListBox.ItemsPanel>
   </ListBox>
     → 【仮想化が無効になる】★
     → 画像のサムネイル一覧などで件数が多いと重い

【対策】
   ・OSS の VirtualizingWrapPanel を使う
   ・または ListView + GridView / UniformGrid + ページング

• 列と行で構成されているグリッド領域を定義する。
  ※ グリッド内のすべてのセルが同じサイズである必要がある。
  • XAML
    • 3 行 * 4 列

<UniformGrid Rows="3" Columns="4"> 
  <Button Width="26" Height="26" Margin="4" Content="0"></Button>
  <Button Width="26" Height="26" Margin="4" Content="1"></Button>
  <Button Width="26" Height="26" Margin="4" Content="2"></Button>
　・・・
  <Button Width="26" Height="26" Margin="4" Content="7"></Button>
  <Button Width="26" Height="26" Margin="4" Content="8"></Button>
  <Button Width="26" Height="26" Margin="4" Content="9"></Button>
</UniformGrid>

- 4 行 * 3 列

<UniformGrid Rows="4" Columns="3">
  <Button Width="26" Height="26" Margin="4" Content="0"></Button>
  <Button Width="26" Height="26" Margin="4" Content="1"></Button>
  <Button Width="26" Height="26" Margin="4" Content="2"></Button>
　・・・
  <Button Width="26" Height="26" Margin="4" Content="7"></Button>
  <Button Width="26" Height="26" Margin="4" Content="8"></Button>
  <Button Width="26" Height="26" Margin="4" Content="9"></Button>
</UniformGrid>

• レンダリング結果
  • 3 行 * 4 列

- 4 行 * 3 列

• 行・列数は、UniformGrid.Rows、UniformGrid.Columns 属性
  （UniformGrid.Rows・Columns プロパティ）で指定する。

• 参考

  • Microsoft Learn > .NET Framework クラス ライブラリ >
    System.Windows.Controls.UniformGrid クラス
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.controls.primitives.uniformgrid

補足（UniformGrid の名前空間に注意）: 参考リンクの URL が示す通り、
UniformGrid は System.Windows.Controls.Primitives 名前空間にある
（本文の「クラス名」欄は名前空間を省略している）。
XAML では <UniformGrid> と書けるが、
コードから使う場合は using System.Windows.Controls.Primitives; が要る。

【Rows / Columns を省略した場合】
   ・両方省略 → 子要素の数から【正方形に近い形】を自動計算する
   ・Columns だけ指定 → 行数は自動

【使いどころ】
   ・電卓のキーパッド（本サンプルがまさにこれ）
   ・カレンダー
   ・均等配置のボタン群

• 列と行で構成されている柔軟なグリッド領域を定義する。

  • 行・列の定義に Grid.RowDefinitions、Grid.ColumnDefinitions タグを使用する。

    • 「添付プロパティ」である Grid.Row・Grid.Column 属性を使用して子要素をセルへ配置する。
    • 列長・行長の設定も、この属性で指定する。
    • このため HTML のテーブルと使い方は異なる。

  • XAML ( 4 行 * 3 列

<Grid Width="250" Height="100">
  <Grid.ColumnDefinitions>
    <ColumnDefinition />
    <ColumnDefinition />
    <ColumnDefinition />
  </Grid.ColumnDefinitions>
  <Grid.RowDefinitions>
    <RowDefinition />
    <RowDefinition />
    <RowDefinition />
    <RowDefinition />
  </Grid.RowDefinitions>

  <TextBlock Grid.ColumnSpan="3" Grid.Row="0">2005 Products Shipped</TextBlock>
  <TextBlock Grid.Row="1" Grid.Column="0">Quarter 1</TextBlock>
  <TextBlock Grid.Row="1" Grid.Column="1">Quarter 2</TextBlock>
  <TextBlock Grid.Row="1" Grid.Column="2">Quarter 3</TextBlock>
  <TextBlock Grid.Row="2" Grid.Column="0">50000</TextBlock>
  <TextBlock Grid.Row="2" Grid.Column="1">100000</TextBlock>
  <TextBlock Grid.Row="2" Grid.Column="2">150000</TextBlock>
  <TextBlock Grid.ColumnSpan="3" Grid.Row="3">Total Units: 300000</TextBlock>
</Grid>

• レンダリング結果

• なお、ColumnDefinition タグの Width 属性に " n*" と指定することで、比率を指定できる。
  • XAML ( 比率を指定

<Grid>
  <Grid.ColumnDefinitions>
    <ColumnDefinition Width="1*"></ColumnDefinition>
    <ColumnDefinition Width="2*"></ColumnDefinition>
    <ColumnDefinition Width="3*"></ColumnDefinition>
  </Grid.ColumnDefinitions>
  <Grid.RowDefinitions>
    <RowDefinition Height="1*"></RowDefinition>
    <RowDefinition Height="2*"></RowDefinition>
    <RowDefinition Height="3*"></RowDefinition>
  </Grid.RowDefinitions>
</Grid>

• レンダリング結果

• 参考
  • Microsoft Learn > .NET Framework クラス ライブラリ >
    System.Windows.Controls.Grid クラス
    https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.controls.grid

補足（Grid のサイズ指定 3 種）: 業務画面のレイアウトで最も使うパネル
なので、サイズ指定を整理しておく。

【3 種類の指定】★
   Width="Auto"   … 【中身に合わせる】（必要なだけ）
   Width="100"    … 固定（デバイス非依存ピクセル）
   Width="*"      … 【残りを分け合う】（比率。既定）

   Width="2*" と Width="1*" → 残りを 2:1 で分ける
   Width="*"  は "1*" と同じ

【業務画面の典型】
   <Grid.ColumnDefinitions>
     <ColumnDefinition Width="Auto" />   ← ラベル（文字幅に合わせる）
     <ColumnDefinition Width="*" />      ← 入力欄（残り全部）
   </Grid.ColumnDefinitions>

 → 【多言語化してラベルが伸びても崩れない】★
   （[国際化対応項目](MS_InternationalizationItems) の要件を満たす）

【Grid の注意点】
 ① 【Grid.Row / Column の既定は 0】
      → 指定を忘れると全部が左上のセルに重なる
      → 「要素が重なって表示される」の原因 ★
 ② セルは【複数の要素を置ける】（重ねられる）
      → HTML のテーブルと違う点
 ③ SharedSizeGroup で【別の Grid と列幅を揃えられる】
      → 複数の入力行でラベル幅を揃える際に有用
 ④ 行・列が多いとレイアウト計算が重い
      → 単純な積み重ねなら StackPanel の方が軽い

【HTML のテーブルとの違い（原文の指摘の補強）】★
   HTML : <tr><td> の入れ子で構造を表す
   WPF  : 【フラットに並べ、添付プロパティで位置を指定する】
     → 行・列の定義と、子要素の配置が【分離している】
     → 行を挿入すると、以降の Grid.Row を全部書き換える必要がある
       （これが Grid の面倒な点）

ココでは、「外観」に関する設定を行う「スタイル」と「テンプレート」について説明する。

• 参考

  • Microsoft Learn > WPF の基礎 > スタイルとテンプレート：概念
    https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/controls/styling-and-templating

    • スタイルとテンプレート
      https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/controls/styling-and-templating
    • ControlTemplate の作成による既存のコントロールの外観のカスタマイズ
      https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/controls/customizing-the-appearance-of-an-existing-control

  • Microsoft Learn > Windows Presentation Foundation > コントロール

    • コントロールのカスタマイズ > ControlTemplate の例
      https://learn.microsoft.com/ja-jp/dotnet/desktop/wpf/controls/control-styles-and-templates

WPF / Silverlight で外観をカスタマイズする仕組みのこと。

「スタイル」は、UI 要素の「依存関係プロパティ」の一括管理機能を持ち、
これを使用して「外観」に統一性を持たせるための機能である。
「スタイル」は、Style 型のオブジェクトであり、
各 UI 要素（FrameworkElement or FrameworkContentElement）の Style プロパティに
指定可能である。

• 外観に関する値を設定する「プロパティ属性構文」
  以下は、UI 要素の「依存関係プロパティ」に、
  「外観」に関する Fill、Height、Width 属性の属性値を設定する「プロパティ属性構文」である。
  • XAML

<Grid>
  <Ellipse Fill="Blue" Height="80" Width="160"/>
</Grid>

• レンダリング結果

• プロパティ属性構文のスタイル化

  • 上記を、「プロパティ要素構文」を使用して Style 型のオブジェクトを生成し、
    Style プロパティにこれを指定する例を以下に示す。

    • TargetType 属性により、「スタイル」は指定の型（ここでは Ellipse 要素）に適用される。
    • この TargetType 属性による型指定が無いと、
      対象のプロパティの有・無などが判別できないため、型指定は必須となっている。

  • XAML

<Grid>
  <Ellipse>
    <Ellipse.Style>
      <Style TargetType="Ellipse">
        <Setter Property="Fill" Value="Blue"/>
        <Setter Property="Height" Value="80"/>
        <Setter Property="Width" Value="160"/>
      </Style>
    </Ellipse.Style>
  </Ellipse>
</Grid>

• レンダリング結果

• スタイルをリソースとして定義

  • なお、上記の「スタイル」化は、通常のプロパティ設定を冗長に記述しているに過ぎず、
    何の意味もなさない。

  • このため、通常、「スタイル」を「リソース」として定義し、
    各 UI 要素の Style プロパティには StaticResource 参照を使用して設定する。

  • 以下は、x:Key を明示した例である。

    • XAML

<StackPanel>
  <StackPanel.Resources>
    <Style x:Key="EllipseStyle" TargetType="Ellipse">
      <Setter Property="Fill" Value="Blue"/>
      <Setter Property="Height" Value="80"/>
      <Setter Property="Width" Value="160"/>
    </Style>
  </StackPanel.Resources>
  <Ellipse Style="{StaticResource EllipseStyle}"/>
  <Ellipse Style="{StaticResource EllipseStyle}"/>
</StackPanel>

- レンダリング結果

移行メモ（開始タグの欠落）: 「x:Key を明示した例」の XAML は、
移行元では <StackPanel> の開始タグが欠落していた
（<StackPanel.Resources> から始まっている）。
前後の例と同じ構造であることから、
<StackPanel> を補って記載した。

• ベースクラスの型にスタイルを適用
  また、派生元（ここでは Shape 型）が同じであれば、
  異なる要素でも同じ「スタイル」を適用できる。
  • XAML

<StackPanel>
  <StackPanel.Resources>
    <Style x:Key="ShapeStyle" TargetType="Shape">
      <Setter Property="Fill" Value="Blue"/>
      <Setter Property="Height" Value="80"/>
      <Setter Property="Width" Value="160"/>
    </Style>
  </StackPanel.Resources>
  <Ellipse Style="{StaticResource ShapeStyle}"/>
  <Rectangle Style="{StaticResource ShapeStyle}"/>
</StackPanel>

• レンダリング結果

• スタイルを全体に適用する例
  x:Key を設定しなければ、TargetType 属性により、
  「スタイル」は指定の型（ここでは Ellipse 型）、全体に適用される
  （ただし、派生元が同じだが、型の異なる全ての要素に「スタイル」を
  適用することはできない）。
  • XAML

<StackPanel>
  <StackPanel.Resources>
    <Style TargetType="Ellipse">
      <Setter Property="Fill" Value="Blue"/>
      <Setter Property="Height" Value="80"/>
      <Setter Property="Width" Value="160"/>
    </Style>
  </StackPanel.Resources>
  <Ellipse/>
  <Ellipse/>
</StackPanel>

• レンダリング結果

補足（「暗黙のスタイル」と、その落とし穴）: x:Key を付けない
スタイルを**暗黙のスタイル（Implicit Style）**と呼ぶ。
実務で最もよく使うが、注意点がある。

【仕組み】
   x:Key を省略すると、
   【TargetType の型そのものが x:Key になる】★
     <Style TargetType="Ellipse">
       ≒ <Style x:Key="{x:Type Ellipse}" TargetType="Ellipse">

【原文の括弧書きが指摘する重要な制約】★
   暗黙のスタイルは【完全一致】でのみ適用される
     <Style TargetType="Shape"> を暗黙で書いても、
     Ellipse / Rectangle には【適用されない】
     → 型が Shape そのものの要素にしか当たらない

   → 派生型にも当てたいなら、
     各型ごとに BasedOn で継承した暗黙スタイルを定義する

<Style x:Key="ShapeBase" TargetType="Shape">...</Style>
<Style TargetType="Ellipse"   BasedOn="{StaticResource ShapeBase}" />
<Style TargetType="Rectangle" BasedOn="{StaticResource ShapeBase}" />

【暗黙のスタイルの落とし穴】
 ① 【スコープ内の全要素に当たる】
      → App.xaml に書くと、アプリ全体の Button が変わる
      → 意図しない箇所まで変わって驚くことになる
 ② カスタム コントロールで BasedOn を書き忘れると、
    【既定のスタイルが失われる】
      <Style TargetType="Button"
             BasedOn="{StaticResource {x:Type Button}}">  ← これが必要 ★
 ③ DataGrid 等の複合コントロールでは、
    内部の TextBlock にも当たってしまう

• TargetType プロパティが同じ２つの Style クラスを定義し、
  BasedOn プロパティに継承元となる Style クラスを設定することで、

  「スタイル」の継承が可能である。

  （Silverlight 2 の Style クラスには BasedOn プロパティが存在しなかったが、
  Silverlight 3 で追加されている）

• スタイルの継承例

  • XAML

<StackPanel>
  <StackPanel.Resources>
    <Style x:Key="EllipseBaseStyle" TargetType="Ellipse">
      <Setter Property="Fill" Value="Blue"/>
      <Setter Property="Height" Value="80"/>
      <Setter Property="Width" Value="160"/>
    </Style>
    <Style x:Key="EllipseInheritedStyle" TargetType="Ellipse"
      BasedOn="{StaticResource EllipseBaseStyle}">
      <Setter Property="Stroke" Value="Yellow"/>
      <Setter Property="StrokeThickness" Value="10"/>
    </Style>
  </StackPanel.Resources>
  <Ellipse Style="{StaticResource EllipseBaseStyle}"/>
  <Ellipse Style="{StaticResource EllipseInheritedStyle}"/>
 </StackPanel>

• レンダリング結果

補足（BasedOn は「TargetType が同じ」だけではない）: 原文の
「TargetType プロパティが同じ２つの Style クラス」という条件は、
正確には「継承元の TargetType が、継承先の TargetType の基底型であればよい」
である。

<!-- 基底型のスタイルを継承できる ★ -->
<Style x:Key="ShapeBase" TargetType="Shape">...</Style>
<Style TargetType="Ellipse" BasedOn="{StaticResource ShapeBase}">...</Style>

【実務での設計】★
   アプリ全体で 1 つの「基底スタイル」を作り、
   各所でそれを BasedOn で継承する

   BaseTextStyle（フォント、色）
     ├ HeaderTextStyle（大きく太く）
     ├ ErrorTextStyle（赤く）
     └ CaptionTextStyle（小さく灰色）

 → 【CSS のカスケーディングに相当する】
 → フォントを変えるときは基底 1 箇所で済む

• 「ディクショナリ ファイル」を使用して、CSS ファイルのように、
  「スタイル」を外部ディクショナリ ファイルに定義することも可能である。

• 以下は、「ディクショナリ ファイル」を使用する例である。

  • XAML

<Window.Resources>
  <ResourceDictionary Source="Dictionary1.xaml"/>
</Window.Resources>
<StackPanel>
  <StackPanel.Resources>
    <Style x:Key="EllipseInheritedStyle" TargetType="Ellipse"
      BasedOn="{StaticResource EllipseBaseStyle}">
      <Setter Property="Stroke" Value="Yellow"/>
      <Setter Property="StrokeThickness" Value="10"/>
    </Style>
  </StackPanel.Resources>
  <Ellipse Style="{StaticResource EllipseBaseStyle}"/>
  <Ellipse Style="{StaticResource EllipseInheritedStyle}"/>
</StackPanel>

• XAML ( 外部ディクショナリ ファイル : Dictionary1.xaml

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <Style x:Key="EllipseBaseStyle" TargetType="Ellipse">
    <Setter Property="Fill" Value="Blue"/>
    <Setter Property="Height" Value="80"/>
    <Setter Property="Width" Value="160"/>
  </Style>
</ResourceDictionary>

補足（「CSS のように」という比喩の当否）: 原文の比喩は分かりやすいが、
CSS と決定的に違う点があるので明示しておく。

	CSS	WPF のスタイル
適用対象の指定	セレクタ（要素、クラス、ID、子孫、擬似クラス）	型（TargetType）または明示的な Key のみ ★
「クラス」の概念	class="a b c" で複数当てられる	1 つの Style しか当てられない
カスケード	複数のルールが合成される	BasedOn で継承（合成ではない）
子孫セレクタ	div p { }	ない
適用範囲	ドキュメント全体	リソースのスコープ

【最も不便な点】★
   「複数のスタイルを組み合わせる」ができない
     CSS : class="rounded shadow large"
     WPF : Style を 1 つしか指定できない

 【回避策】
   ・BasedOn で継承の連鎖を作る（組み合わせ爆発する）
   ・添付プロパティ + トリガーで部分的に付け外しする
   ・OSS のライブラリ（MahApps 等）は
     「複数のスタイルを合成する」ヘルパーを提供している

• 「リソースの定義と参照」の

  • DynamicResource 参照
  • ディクショナリ ファイル

  の方法を、「スタイル」でも応用可能である。

• 上記の例の XAML を以下のように書き換え、
  コード ビハインドから ResourceDictionary を切り換え
  「スタイル」（スキン）を実行時に、動的に切り換えることができる。

  • XAML

<StackPanel>
  <Ellipse Style="{DynamicResource MyEllipseStyle}"/>
  <Button Content="青" Height="23" Name="button1" Width="75" Click="button1_Click" />
  <Button Content="赤" Height="23" Name="button2" Width="75" Click="button2_Click" />
</StackPanel>

• XAML ( 外部ディクショナリ ファイル :
  • Dictionary1.xaml

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <Style x:Key="MyEllipseStyle" TargetType="Ellipse">
    <Setter Property="Fill" Value="Blue"/>
    <Setter Property="Height" Value="80"/>
    <Setter Property="Width" Value="160"/>
  </Style>
</ResourceDictionary>

- Dictionary2.xaml

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Style x:Key="MyEllipseStyle" TargetType="Ellipse">
        <Setter Property="Fill" Value="Red"/>
        <Setter Property="Height" Value="160"/>
        <Setter Property="Width" Value="80"/>
    </Style>
</ResourceDictionary>

• コード・ビハインド

public partial class Window1 : Window {
  public Window1() {
    InitializeComponent();
    this.LoadResourceDictionary("Dictionary1.xaml");
  }

  private void button1_Click(object sender, RoutedEventArgs e) {
    this.LoadResourceDictionary("Dictionary1.xaml");
  }

  private void button2_Click(object sender, RoutedEventArgs e) {
    this.LoadResourceDictionary("Dictionary2.xaml");
  }

  private void LoadResourceDictionary(string name) {
    ResourceDictionary dictionary =
      (ResourceDictionary)Application.LoadComponent(new Uri(name, UriKind.Relative));
    if (dictionary != null) Application.Current.Resources = dictionary;
  }
}