XAML の概要XAML overview

ここでは、Windows ランタイム アプリの開発者を対象に、XAML 言語と XAML の概念を紹介し、Windows ランタイム アプリを作成する際に XAML でオブジェクトを宣言したり属性を設定したりするためのさまざまな方法について説明します。We introduce the XAML language and XAML concepts to the Windows Runtime app developer audience, and describe the different ways to declare objects and set attributes in XAML as it is used for creating a Windows Runtime app.

XAML とはWhat is XAML?

XAML (Extensible Application Markup Language) は宣言型言語の一種です。Extensible Application Markup Language (XAML) is a declarative language. 具体的には、XAML では、複数のオブジェクトの間の階層的な関係を示す言語構造と、型の拡張をサポートするバッキング型変換を使って、オブジェクトの初期化とオブジェクトのプロパティの設定を行うことができます。Specifically, XAML can initialize objects and set properties of objects, using a language structure that shows hierarchical relationships between multiple objects, and using a backing type convention that supports extension of types. 表示される UI 要素を宣言型 XAML マークアップで作成できます。You can create visible UI elements in the declarative XAML markup. さらに、各 XAML ファイルに別のコード ビハインド ファイルを関連付けて、イベントに応答することも、XAML で宣言したオブジェクトを操作することもできます。You can then associate a separate code-behind file for each XAML file that can respond to events and manipulate the objects that you originally declare in XAML.

XAML 言語では、開発プロセスにおけるさまざまなツールや役割の間でソースを交換できます。たとえば、デザイン ツールと IDE の間や、メインの開発者とローカライズを担当する開発者の間で XAML ソースを交換できます。The XAML language supports interchange of sources between different tools and roles in the development process, such as exchanging XAML sources between design tools and an IDE, or between primary developers and localization developers. 交換形式として XAML を使うことで、デザイナーと開発者の役割を分離または結合して、それぞれがアプリの制作中に反復的な作業を行うことができます。By using XAML as the interchange format, designer roles and developer roles can be kept separate or brought together, and designers and developers can iterate during the production of an app.

Windows ランタイム アプリ プロジェクトの一部としてみた場合、XAML ファイルは .xaml というファイル名拡張子を持つ XML ファイルです。When you see them as part of your Windows Runtime app projects, XAML files are XML files with the .xaml file name extension.

基本的な XAML 構文Basic XAML syntax

XAML には、XML に基づく基本的な構文があります。XAML has a basic syntax that builds on XML. 定義上、有効な XAML は、有効な XML でもある必要があります。By definition, valid XAML must also be valid XML. しかし、XAML には、XML 1.0 仕様に基づいて有効な XML でありつつも、別のより完全な意味が割り当てられた構文概念もあります。But XAML also has syntax concepts that are assigned a different and more complete meaning, while still being valid in XML per the XML 1.0 specification. たとえば、属性の文字列値またはコンテンツとしてではなく要素内でプロパティ値を設定できるプロパティ要素構文がサポートされています。For example, XAML supports property element syntax, where property values can be set within elements rather than as string values in attributes or as content. 標準 XML と比較すると、XAML プロパティ要素は、名前にドットを含む要素であるため、プレーン XML でも有効ではありますが、同じ意味にはなりません。To regular XML, a XAML property element is an element with a dot in its name, so it's valid to plain XML but doesn't have the same meaning.

XAML と Microsoft Visual StudioXAML and Microsoft Visual Studio

Microsoft Visual Studio では、XAML テキスト エディターでも、もっとグラフィカル指向の XAML デザイン サーフェイスでも、有効な XAML 構文の生成を支援する機能を使うことができます。Microsoft Visual Studio helps you to produce valid XAML syntax, both in the XAML text editor and in the more graphically oriented XAML design surface. そのため、Visual Studio を使ってアプリの XAML を作成するときは、キー入力のたびに構文を気にかける必要はありません。So when you write XAML for your app using Visual Studio, don't worry too much about the syntax with each keystroke. IDE は有効な XAML 構文を記述できるように支援してくれます。たとえば、オート コンプリートによるヒント、Microsoft IntelliSense でのドロップダウン リストによる候補の表示、ツールボックスでの UI 要素ライブラリの表示などの機能があります。The IDE encourages valid XAML syntax by providing autocompletion hints, showing suggestions in Microsoft IntelliSense lists and dropdowns, showing UI element libraries in the toolbox, or other techniques. それでも、XAML を初めて使う場合は、XAML 構文の規則と、リファレンスなどのトピックでの XAML 構文の解説で制限や選択肢の説明に使われることがある用語を確認しておくと役に立ちます。If this is your first experience with XAML, it might still be useful to know the syntax rules and particularly the terminology that is sometimes used to describe the restrictions or choices when we describe XAML syntax in reference or other topics. XAML 構文の細かな点について詳しくは、「XAML 構文のガイド」をご覧ください。We cover these fine points of XAML syntax in a separate topic, XAML syntax guide.

XAML 名前空間XAML namespaces

一般的なプログラミングでは、名前空間とは、プログラミング エンティティの識別子がどのように解釈されるかを決定する、整理のための概念です。In general programming, a namespace is an organizing concept that determines how identifiers for programming entities are interpreted. 名前空間を使うことで、プログラミング フレームワークは、ユーザーが宣言した識別子とフレームワークで宣言された識別子を区別し、名前空間の修飾により識別子を明確化し、名前スコープの規則を強制的に適用したりすることができます。By using namespaces, a programming framework can separate user-declared identifiers from framework-declared identifiers, disambiguate identifiers through namespace qualifications, enforce rules for scoping names, and so on. XAML には、XAML 言語でこの目的を果たすための独自の XAML 名前空間の概念があります。XAML has its own XAML namespace concept that serves this purpose for the XAML language. XAML では、XML 言語の名前空間の概念が次のように応用および拡張されています。Here's how XAML applies and extends the XML language namespace concepts:

  • XAML は、名前空間の宣言のために予約された XML 属性 xmlns を使います。XAML uses the reserved XML attribute xmlns for namespace declarations. この属性の値は、通常は、Uniform Resource Identifier (URI) です。これは XML から継承した慣例です。The value of the attribute is typically a Uniform Resource Identifier (URI), which is a convention inherited from XML.
  • XAML では、宣言でプレフィックスを使って既定以外の名前空間を宣言し、要素や属性内でプレフィックスを使うことでその名前空間を参照します。XAML uses prefixes in declarations to declare non-default namespaces, and prefix usages in elements and attributes reference that namespace.
  • XAML には、使用時または宣言時にプレフィックスが付いていないときに使う名前空間である既定の名前空間という概念があります。XAML has a concept of a default namespace, which is the namespace used when no prefix exists in a usage or declaration. 既定の名前空間は、XAML プログラミング フレームワークそれぞれに異なる名前空間を定義することができます。The default namespace can be defined differently for each XAML programming framework.
  • 名前空間の定義は、XAML ファイルまたはコンストラクト内で親要素から子要素に継承されます。Namespace definitions inherit in a XAML file or construct, from parent element to child element. たとえば XAML ファイルのルート要素の名前空間を定義する場合、そのファイル内のすべての要素はその名前空間の定義を継承します。For example if you define a namespace in the root element of a XAML file, all elements within that file inherit that namespace definition. ページへの要素がさらに名前空間を定義し直した場合、その要素の子孫は新しい定義を継承します。If an element further into the page redefines the namespace, that element's descendants inherit the new definition.
  • 要素の属性は、要素の名前空間を継承します。Attributes of an element inherit the element's namespaces. XAML 属性でプレフィックスが使用されることはかなりまれです。It's fairly uncommon to see prefixes on XAML attributes.

ほとんどの場合、XAML ファイルでは、既定の XAML 名前空間をルート要素で宣言します。A XAML file almost always declares a default XAML namespace in its root element. 既定の XAML 名前空間は、プレフィックスで修飾することなく宣言できる要素を定義します。The default XAML namespace defines which elements you can declare without qualifying them by a prefix. 一般的な Windows ランタイム アプリ プロジェクトの場合、この既定の名前空間には、UI 定義で使われる Windows ランタイムの組み込み XAML ボキャブラリがすべて含まれます。これは既定のコントロール、テキスト要素、XAML グラフィックス、アニメーション、データバインド、スタイル サポートの種類などを含みます。For typical Windows Runtime app projects, this default namespace contains all the built-in XAML vocabulary for the Windows Runtime that's used for UI definitions: the default controls, text elements, XAML graphics and animations, databinding and styling support types, and so on. こうして、Windows ランタイム アプリ用に作成する XAML の大半は、一般的な UI 要素を参照するときに XAML の名前空間とプレフィックスを使うことを避けられます。Most of the XAML you'll write for Windows Runtime apps will thus be able to avoid using XAML namespaces and prefixes when referring to common UI elements.

次のスニペットは、テンプレートを使って作成された、アプリの開始ページの Page ルートです (開始タグのみを表し、以降は省略しています)。Here's a snippet showing a template-created Page root of the initial page for an app (showing the opening tag only, and simplified). これは既定の名前空間を宣言し、x 名前空間 (次に説明) も宣言しています。It declares the default namespace and also the x namespace (which we'll explain next).

<Page
    x:Class="Application1.BlankPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>

XAML 言語の XAML 名前空間The XAML-language XAML namespace

ほぼすべての Windows ランタイム XAML ファイルで宣言される特定の XAML 名前空間が、XAML 言語の名前空間です。One particular XAML namespace that is declared in nearly every Windows Runtime XAML file is the XAML-language namespace. この名前空間は、言語仕様に従って XAML 言語で定義される要素と概念を含みます。This namespace includes elements and concepts that are defined by the XAML language, by its language specification. 慣例として、XAML 言語の XAML 名前空間はプレフィックス "x" にマップされます。By convention, the XAML-language XAML namespace is mapped to the prefix "x". Windows ランタイム アプリ プロジェクトの既定のプロジェクト テンプレートとファイル テンプレートでは、既定の XAML 名前空間 (プレフィックスなし、xmlns= のみ) と XAML 言語の XAML 名前空間 (プレフィックス "x") の両方がルート要素の一部として必ず定義されます。The default project and file templates for Windows Runtime app projects always define both the default XAML namespace (no prefix, just xmlns=) and the XAML-language XAML namespace (prefix "x") as part of the root element.

"x" プレフィックス/XAML 言語の XAML 名前空間には、XAML でよく使われるプログラミング構成要素がいくつか存在します。The "x" prefix/XAML-language XAML namespace contains several programming constructs that you use often in your XAML. 代表的なコントロールをいくつか次に示します。Here are the most common ones:

用語Term 説明Description
x: キーx:Key XAML ResourceDictionary 内の各リソースにユーザー定義の一意のキーを設定します。Sets a unique user-defined key for each resource in a XAML ResourceDictionary. このキー トークンの文字列は、StaticResource マークアップ拡張の引数であり、後でこのキーを使って、アプリの XAML のどこかで使われた別の XAML の XAML リソースを取得することができます。The key's token string is the argument for the StaticResource markup extension, and you use this key later to retrieve the XAML resource from another XAML usage elsewhere in your app's XAML.
x: クラスx:Class XAML ページのコード ビハインドを提供するクラスのコード名前空間とコード クラス名を指定します。Specifies the code namespace and code class name for the class that provides code-behind for a XAML page. これによって、アプリのビルド時にビルド アクションによって作成または結合されたクラスの名前が付けられます。This names the class that is created or joined by the build actions when you build your app. これらのビルド アクションは、XAML マークアップ コンパイラをサポートし、アプリがコンパイルされるときにマークアップとコード ビハインドを組み合わせます。These build actions support the XAML markup compiler and combine your markup and code-behind when the app is compiled. XAML ページのコード ビハインドをサポートするには、このようなクラスが必要です。You must have such a class to support code-behind for a XAML page. Window.Content で既定の Windows ランタイムのアクティブ化モデル。Window.Content in the default Windows Runtime activation model.
x: 名前です。x:Name XAML で定義されたオブジェクト要素が処理された後のランタイム コードに存在するインスタンスのランタイム オブジェクト名を指定します。Specifies a run-time object name for the instance that exists in run-time code after an object element defined in XAML is processed. XAML で x:Name を設定することは、コードで名前付き変数を宣言するようなものと考えることができます。You can think of setting x:Name in XAML as being like declaring a named variable in code. 後でわかるように、これは、まさに Windows ランタイム アプリのコンポーネントとして XAML を読み込むときに起こることです。As you'll learn later, that's exactly what happens when your XAML is loaded as a component of a Windows Runtime app.
  FrameworkElement.Name は、フレームワークの同様のプロパティと同じですが、すべての要素でサポートされているわけではありません。Note  FrameworkElement.Name is a similar property in the framework but not all elements support it. そのため、その要素型で FrameworkElement.Name がサポートされていない場合はいつでも、要素 ID に x:Name を使用できます。So you use x:Name for element identification, whenever FrameworkElement.Name is not supported on that element type.
x: Uidx:Uid 一部のプロパティ値にローカライズされたリソースを使う必要がある要素を識別します。Identifies elements that should use localized resources for some of their property values. 使用する方法の詳細についてはX:uidを参照してくださいクイック スタート。UI リソースを翻訳するします。For more info on how to use x:Uid, see Quickstart: Translating UI resources.
XAML の組み込みのデータ型XAML intrinsic data types これらの型では、属性やリソースで必要となるときに、単純な値型の値を指定できます。These types can specify values for simple value-types when that's required for an attribute or resource. この本質的な型は、各プログラミング言語に固有の定義の一部として一般的に定義される単純な値型に対応しています。These intrinsic types correspond to the simple value types that are typically defined as part of each programming language's intrinsic definitions. たとえば、ObjectAnimationUsingKeyFrames のストーリーボードに設定された表示状態で使うブール値に対応する true を表すオブジェクトが必要になることがあります。For example, you might need an object representing a true Boolean value to use in an ObjectAnimationUsingKeyFrames storyboarded visual state. XAML では、その値を使用して、 : ブール値を x次のように、オブジェクト要素と組み込みの型。 <x:Boolean>True</x:Boolean>For that value in XAML, you'd use the x:Boolean intrinsic type as the object element, like this: <x:Boolean>True</x:Boolean>  

XAML 言語の XAML 名前空間には、その他のプログラミング構成要素もありますが、あまり一般的ではありません。Other programming constructs in the XAML-language XAML namespace exist but are not as common.

XAML 名前空間へのカスタム型のマッピングMapping custom types to XAML namespaces

XAML の言語として最も強力な機能の 1 つが、Windows ランタイム アプリの XAML ボキャブラリを簡単に拡張できることです。One of the most powerful aspects of XAML as a language is that it's easy to extend the XAML vocabulary for your Windows Runtime apps. アプリのプログラミング言語で独自のカスタム型を定義でき、XAML マークアップでそのカスタム型を参照できます。You can define your own custom types in your app's programming language and then reference your custom types in XAML markup. カスタム型による機能拡張のサポートは、基本的に XAML 言語のしくみに組み込まれています。Support for extension through custom types is fundamentally built-in to how the XAML language works. フレームワークやアプリの開発者は、XAML が参照するバッキング オブジェクトを作成する責任を負います。Frameworks or app developers are responsible for creating the backing objects that XAML references. フレームワークもアプリ開発者も、ボキャブラリ内のオブジェクトが何を表現し、基本的な XAML 構文規則を超えて何を行うかについて仕様にバインドされることはありません (XAML 言語の XAML 名前空間の型がなすべきことについて期待されることはありますが、Windows ランタイムはすべての必要なサポートを提供しています)。Neither frameworks nor the app developer are bound by specifications of what the objects in their vocabularies represent or do beyond the basic XAML syntax rules (there are some expectations of what the XAML-language XAML namespace types should do, but the Windows Runtime provides all the necessary support).

Windows ランタイム コア ライブラリ以外のライブラリとメタデータに含まれる型のために XAML を使う場合は、プレフィックスを使って XAML 名前空間を宣言およびマップする必要があります。If you use XAML for types that come from libraries other than the Windows Runtime core libraries and metadata, you must declare and map a XAML namespace with a prefix. ライブラリで定義された型を参照するには、要素を使うときにそのプレフィックスを使います。Use that prefix in element usages to reference the types that were defined in your library. プレフィックス マッピングは、通常はルート要素で、その他の XAML 名前空間定義と一緒に、xmlns 属性として宣言します。You declare prefix mappings as xmlns attributes, typically in a root element along with the other XAML namespace definitions.

カスタム型を参照する独自の名前空間定義を行うには、キーワード xmlns: に続けて目的のプレフィックスを指定します。To make your own namespace definition that references custom types, you first specify the keyword xmlns:, then the prefix you want. この属性の値には、先頭部分にキーワード using: を含める必要があります。The value of that attribute must contain the keyword using: as the first part of the value. 値の残り部分は、カスタム型を含む特定のコード バッキング名前空間を名前で参照する文字列トークンです。The remainder of the value is a string token that references the specific code-backing namespace that contains your custom types, by name.

プレフィックスは、その XAML ファイル内の残りのマークアップでその XAML 名前空間を参照するために使われるマークアップ トークンを定義します。The prefix defines the markup token that is used to refer to that XAML namespace in the remainder of the markup in that XAML file. プレフィックスと、XAML 名前空間内で参照されるエンティティの間は、コロン (:) で区切ります。A colon character (:) goes between the prefix and the entity to be referenced within the XAML namespace.

たとえば、プレフィックス myTypes を名前空間 myCompany.myTypes にマップする属性構文は xmlns:myTypes="using:myCompany.myTypes" で、代表的な要素の使用方法は <myTypes:CustomButton/> のようになります。For example, the attribute syntax to map a prefix myTypes to the namespace myCompany.myTypes is: xmlns:myTypes="using:myCompany.myTypes", and a representative element usage is: <myTypes:CustomButton/>

カスタムの型のマッピングの XAML 名前空間の詳細については、Visual C コンポーネント拡張に関する注意事項を含む (C +/cli CX) を参照してくださいXAML 名前空間と名前空間マッピングします。For more info on mapping XAML namespaces for custom types, including special considerations for Visual C++ component extensions (C++/CX), see XAML namespaces and namespace mapping.

その他の XAML 名前空間Other XAML namespaces

プレフィックス "d" (デザイナー名前空間を示す) や、プレフィックス "mc" (マークアップ互換性を示す) を定義している XAML ファイルもよく使われます。You often see XAML files that define the prefixes "d" (for designer namespace) and "mc" (for markup compatibility). 一般に、これらはインフラストラクチャ サポートのために使うか、設計時のツールでシナリオを実現するために使います。Generally these are for infrastructure support, or to enable scenarios in a design-time tool. 詳しくは、「XAML 名前空間」トピックの「その他の XAML 名前空間」セクションをご覧ください。For more info, see the "Other XAML namespaces" section of the XAML namespaces topic.

マークアップ拡張機能Markup extensions

マークアップ拡張は、XAML 言語の概念であり、Windows ランタイム XAML 実装でよく使われています。Markup extensions are a XAML language concept that is often used in the Windows Runtime XAML implementation. マークアップ拡張は、しばしば、単純にバッキング型に基づいて要素を宣言するのとは違って、値または挙動に XAML ファイルでアクセスできる、ある種の "ショートカット" を表します。Markup extensions often represent some kind of "shortcut" that enables a XAML file to access a value or behavior that isn't simply declaring elements based on backing types. マークアップ拡張によっては、構文の合理化、または、異なる XAML ファイル間での整理を目標として、プレーン文字列や入れ子になった追加要素を使ってプロパティを設定できます。Some markup extensions can set properties with plain strings or with additionally nested elements, with the goal of streamlining the syntax or the factoring between different XAML files.

XAML 属性構文では、中かっこ ("{" と "}") によって XAML マークアップ拡張を使っていることを示します。In XAML attribute syntax, curly braces "{" and "}" indicate a XAML markup extension usage. これにより、XAML プロセッサの通常の処理 (リテラル文字列か、直接文字列に変換できる値のいずれかとして属性値を扱う処理) がエスケープされます。This usage directs the XAML processing to escape from the general treatment of treating attribute values as either a literal string or a directly string-convertible value. 代わりに、XAML パーサーが特定のマークアップ拡張の動作を実現するコードを呼び出し、そのコードが XAML パーサーの必要とする代替オブジェクトまたは動作結果を用意します。Instead, a XAML parser calls code that provides behavior for that particular markup extension, and that code provides an alternate object or behavior result that the XAML parser needs. マークアップ拡張は引数を取ることができ、引数はマークアップ拡張名に従い、中かっこ内に含めることもできます。Markup extensions can have arguments, which follow the markup extension name and are also contained within the curly braces. 通常、評価されたマークアップ拡張には、オブジェクトの戻り値が用意されています。Typically, an evaluated markup extension provides an object return value. 解析時に、ソース XAML でマークアップ拡張が使われていたオブジェクト ツリーの位置にその戻り値が挿入されます。During parsing, that return value is inserted into the position in the object tree where the markup extension usage was in the source XAML.

Windows ランタイム XAML は、既定の XAML 名前空間で定義され、Windows ランタイム XAML パーサーが認識できる次のマークアップ拡張をサポートしています。Windows Runtime XAML supports these markup extensions that are defined under the default XAML namespace and are understood by the Windows Runtime XAML parser:

  • {{xBind}}: コンパイル時に生成される特定用途のコードを実行することで、プロパティの評価が実行時まで遅延されるデータ バインディングをサポートします。{xBind}: supports data binding, which defers property evaluation until run-time by executing special-purpose code, which it generates at compile-time. このマークアップ拡張は、さまざまな引数をサポートしています。This markup extension supports a wide range of arguments.
  • {Binding}: 汎用的なランタイム オブジェクト検査を実行することで、プロパティの評価が実行時まで遅延されるデータ バインディングをサポートします。{Binding}: supports data binding, which defers property evaluation until run-time by executing general-purpose runtime object inspection. このマークアップ拡張は、さまざまな引数をサポートしています。This markup extension supports a wide range of arguments.
  • {StaticResource}: ResourceDictionary で定義されているリソース値の参照をサポートします。{StaticResource}: supports referencing resource values that are defined in a ResourceDictionary. これらのリソースは、異なる XAML ファイルに存在していてもかまいませんが、最終的には読み込み時に XAML パーサーによって検出できる必要があります。These resources can be in a different XAML file but must ultimately be findable by the XAML parser at load time. {StaticResource} の使用時の引数は、ResourceDictionary 内のキーを持つリソースのキー (名前) を識別します。The argument of a {StaticResource} usage identifies the key (the name) for a keyed resource in a ResourceDictionary.
  • {{ThemeResource}}: {{StaticResource}} と似ていますが、実行時のテーマ変更に応答できます。{ThemeResource}: similar to {StaticResource} but can respond to run-time theme changes. {ThemeResource} は、Windows ランタイムの既定の XAML テンプレートによく出現します。これらのテンプレートのほとんどは、アプリの実行中にユーザーがテーマを切り替えた場合に対応できるように設計されているためです。{ThemeResource} appears quite often in the Windows Runtime default XAML templates, because most of these templates are designed for compatibility with the user switching the theme while the app is running.
  • {{TemplateBinding}}: {{Binding}} の特殊なケースであり、XAML のコントロール テンプレートとその実行時の最終的な使用をサポートします。{TemplateBinding}: a special case of {Binding} that supports control templates in XAML and their eventual usage at run time.
  • {RelativeSource}: テンプレート化された親に値が由来する特定の形式のテンプレート バインディングを有効にします。{RelativeSource}: enables a particular form of template binding where values come from the templated parent.
  • {CustomResource}: 高度なリソース検索のシナリオで使います。{CustomResource}: for advanced resource lookup scenarios.

Windows ランタイムは、{x:Null} マークアップ拡張もサポートしています。Windows Runtime also supports the {x:Null} markup extension. これは、XAML で Nullable 値を null に設定するために使われます。You use this to set Nullable values to null in XAML. たとえば、CheckBox のコントロール テンプレートでこれを使うと、null は不確定なチェック状態として解釈されます ("Indeterminate" 表示状態がトリガーされます)。For example you might use this in a control template for a CheckBox, which interprets null as an indeterminate check state (triggering the "Indeterminate" visual state).

一般に、マークアップ拡張では、アプリのオブジェクト グラフの他の部分から既存のインスタンスが返されるか、値が実行時まで保留されます。A markup extension generally return an existing instance from some other part of the object graph for the app, or defers a value to run time. マークアップ拡張は属性値として使うことができ、それが一般的な使用方法であるため、マークアップ拡張は多くの場合、マークアップ拡張を使用しなければプロパティ要素構文が必要である参照型のプロパティの値を設定するために使用されます。Because you can use a markup extension as an attribute value, and that's the typical usage, you often see markup extensions providing values for reference-type properties that might have otherwise required a property element syntax.

たとえば、再利用可能な StyleResourceDictionary から参照するための構文は、<Button Style="{StaticResource SearchButtonStyle}"/> です。For example, here's the syntax for referencing a reusable Style from a ResourceDictionary: <Button Style="{StaticResource SearchButtonStyle}"/>. Style は参照型であり、単純値ではないため、{StaticResource} を使わない場合は、FrameworkElement.Style プロパティを設定するために、<Button.Style> プロパティ要素と、その中の <Style> 定義が必要になります。A Style is a reference type, not a simple value, so without the {StaticResource} usage, you would've needed a <Button.Style> property element and a <Style> definition within it to set the FrameworkElement.Style property.

マークアップ拡張を使うと、XAML で設定可能なすべてのプロパティを属性構文で設定できるようになる可能性があります。By using markup extensions, every property that is settable in XAML is potentially settable in attribute syntax. 属性構文でオブジェクトを直接インスタンス化できないプロパティでも、属性構文を使って、プロパティの参照値を指定できます。You can use attribute syntax to provide reference values for a property even if it doesn't otherwise support an attribute syntax for direct object instantiation. つまり、XAML のプロパティに値型または新しく作成した参照型を設定するという通常の要件を延期する特殊な動作を有効にすることができます。Or you can enable specific behavior that defers the general requirement that XAML properties be filled by value types or by newly created reference types.

次の XAML の例では、属性構文を使って、BorderStyle プロパティの値を設定します。To illustrate, the next XAML example sets the value of the Style property of a Border by using attribute syntax. Style プロパティは、Style クラスのインスタンスを受け取ります。このインスタンスは、参照型であるため、既定では属性構文の文字列を使って作成することはできません。The Style property takes an instance of the Style class, a reference type that by default could not be created using an attribute syntax string. しかし、この例では、属性が StaticResource のマークアップ拡張機能を参照しています。But in this case, the attribute references a particular markup extension, StaticResource. このマークアップ拡張が処理されると、リソース ディクショナリ内のキーを持つリソースとして既に定義されている Style 要素への参照が返されます。When that markup extension is processed, it returns a reference to a Style element that was defined earlier as a keyed resource in a resource dictionary.

<Canvas.Resources>
  <Style TargetType="Border" x:Key="PageBackground">
    <Setter Property="BorderBrush" Value="Blue"/>
    <Setter Property="BorderThickness" Value="5"/>
  </Style>
</Canvas.Resources>
...
<Border Style="{StaticResource PageBackground}">
  ...
</Border>

マークアップ拡張は、入れ子にすることもできます。You can nest markup extensions. 一番内側のマークアップ拡張が最初に評価されます。The innermost markup extension is evaluated first.

マークアップ拡張のため、属性内のリテラル "{{" 値には特別な構文が必要です。Because of markup extensions, you need special syntax for a literal "{" value in an attribute. 詳しくは、「XAML 構文のガイド」をご覧ください。For more info see XAML syntax guide.

イベントEvents

XAML は、オブジェクトとそのプロパティを記述するための宣言型言語ですが、マークアップ内のオブジェクトにイベント ハンドラーをアタッチするための構文も備えています。XAML is a declarative language for objects and their properties, but it also includes a syntax for attaching event handlers to objects in the markup. XAML イベント構文では、Windows ランタイム プログラミング モデルを利用して、XAML で宣言されたイベントを統合できます。The XAML event syntax can then integrate the XAML-declared events through the Windows Runtime programming model. イベントの名前は、そのイベントが処理されるオブジェクトの属性名として指定します。You specify the name of the event as an attribute name on the object where the event is handled. 属性値には、コードで定義するイベント ハンドラー関数の名前を指定します。For the attribute value, you specify the name of an event-handler function that you define in code. XAML プロセッサはこの名前を使って、読み込まれたオブジェクト ツリーにデリゲート表現を作成し、指定されたハンドラーを内部ハンドラー リストに追加します。The XAML processor uses this name to create a delegate representation in the loaded object tree, and adds the specified handler to an internal handler list. Windows ランタイム アプリの大半は、マークアップ ソースとコード ビハインド ソースの両方によって定義されます。Nearly all Windows Runtime apps are defined by both markup and code-behind sources.

次に単純な例を示します。Here's a simple example. Button クラスは Click という名前のイベントをサポートします。The Button class supports an event named Click. ユーザーが Button をクリックすると呼び出されるコードを実行する Click のハンドラーを作成できます。You can write a handler for Click that runs code that should be invoked after the user clicks the Button. XAML では、ClickButton の属性として指定します。In XAML, you specify Click as an attribute on the Button. 属性値には、ハンドラーのメソッド名である文字列を指定します。For the attribute value, provide a string that is the method name of your handler.

<Button Click="showUpdatesButton-Click">Show updates</Button>

コンパイルの際に、showUpdatesButton-Click という名前のメソッドが、コード ビハインド ファイルと、XAML ページの x:Class 値に宣言された名前空間に定義されていることが前提となります。When you compile, the compiler now expects that there will be a method named showUpdatesButton-Click defined in the code-behind file, in the namespace declared in the XAML page's x:Class value. また、このメソッドは、Click イベントのデリゲート コントラクトを満たす必要があります。Also, that method must satisfy the delegate contract for the Click event. 次に、例を示します。For example:

namespace App1
{
    public sealed partial class MainPage: Page {
        ...
        private void showUpdatesButton_Click (object sender, RoutedEventArgs e) {
            //your code
        }
    }
}
' Namespace included at project level
Public NotInheritable Class MainPage
    Inherits Page
        ...
        Private Sub showUpdatesButton_Click (sender As Object, e As RoutedEventArgs e)
            ' your code
        End Sub
    ...
End Class
namespace winrt::App1::implementation
{
    struct MainPage : MainPageT<MainPage>
    {
        ...
        void showUpdatesButton_Click(Windows::Foundation::IInspectable const&, Windows::UI::Xaml::RoutedEventArgs const&);
    };
}
// .h
namespace App1
{
    public ref class MainPage sealed {
        ...
    private:
        void showUpdatesButton_Click(Object^ sender, RoutedEventArgs^ e);
    };
}

1 つのプロジェクトの中で、XAML を使って .xaml ファイルが作成され、任意の言語 (C#、Visual Basic、C++/CX) を使って分離コード ファイルが作成されます。Within a project, the XAML is written as a .xaml file, and you use the language you prefer (C#, Visual Basic, C++/CX) to write a code-behind file. 名前空間とクラスを XAML ページのルート要素の x:Class 属性として指定すると、プロジェクトのビルド アクションの一環として XAML ファイルがマークアップ コンパイルされるときに、各 XAML ページの XAML コード ビハインド ファイルの場所が特定されます。When a XAML file is markup-compiled as part of a build action for the project, the location of the XAML code-behind file for each XAML page is identified by specifying a namespace and class as the x:Class attribute of the root element of the XAML page. これらの機構がどのように XAML で動作し、プログラミングとアプリケーション モデルにどのように関連するかについての詳しい情報は、「イベントとルーティング イベントの概要」をご覧ください。For more info on how these mechanisms work in XAML and how they relate to the programming and application models, see Events and routed events overview.

  の C+/cli が CX は 2 つの分離コード ファイル、ヘッダーは、1 つ (. xaml.h) し、もう一方の実装 (. xaml.cpp)。Note  For C++/CX there are two code-behind files, one is a header (.xaml.h) and the other is implementation (.xaml.cpp). 実装は、ヘッダーを参照し、コード ビハインド接続用のエントリ ポイントを表す技術的なヘッダーです。The implementation references the header, and it's technically the header that represents the entry point for the code-behind connection.

リソース ディクショナリResource dictionaries

ResourceDictionary の作成は、通常はリソース ディクショナリを XAML ページの領域または別の XAML ファイルとして記述すれば完了する、一般的なタスクです。Creating a ResourceDictionary is a common task that is usually accomplished by authoring a resource dictionary as an area of a XAML page or a separate XAML file. リソース ディクショナリとその使用方法は、概念的に広い範囲にわたるので、このトピックでは扱いません。Resource dictionaries and how to use them is a larger conceptual area that is outside the scope of this topic. 詳しくは、「ResourceDictionary と XAML リソースの参照」をご覧ください。For more info see ResourceDictionary and XAML resource references.

XAML と XMLXAML and XML

XAML 言語は、基本的に XML 言語に基づいています。The XAML language is fundamentally based on the XML language. ただし、XAML は XML と比較して大幅に拡張されています。But XAML extends XML significantly. 特にバッキング型の概念に対する関係からスキーマの概念が大きく異なるほか、アタッチされたメンバーやマークアップ拡張などの言語要素が追加されています。In particular it treats the concept of schema quite differently because of its relationship to the backing type concept, and adds language elements such as attached members and markup extensions. xml:lang は XAML で有効ですが、解析動作の際ではなく実行時に作用し、一般的にフレームワーク レベルのプロパティに対するエイリアスが設定されます。xml:lang is valid in XAML, but influences runtime rather than parse behavior, and is typically aliased to a framework-level property. 詳しくは、「FrameworkElement.Language」をご覧ください。For more info, see FrameworkElement.Language. xml:base はマークアップで有効ですが、パーサーでは無視されます。xml:base is valid in markup but parsers ignore it. xml:space は有効ですが、「XAML と空白」で説明されているシナリオ以外では使われません。xml:space is valid, but is only relevant for scenarios described in the XAML and whitespace topic. encoding 属性は XAML で有効です。The encoding attribute is valid in XAML. サポートされているのは UTF-8 エンコードと UTF-16 エンコードだけです。Only UTF-8 and UTF-16 encodings are supported. UTF-32 エンコードはサポートされていません。UTF-32 encoding is not supported.

XAML での大文字と小文字の区別Case sensitivity in XAML

XAML は、大文字と小文字を区別します。XAML is case-sensitive. XAML は XML を基にしているため、XML と同じく大文字と小文字が区別されます。This is another consequence of XAML being based on XML, which is case-sensitive. XAML 要素と属性の名前では、大文字と小文字が区別されます。The names of XAML elements and attributes are case-sensitive. 属性の値は、場合によって大文字と小文字が区別されます。これは、特定のプロパティに対して属性値がどのように処理されるかによって決まります。The value of an attribute is potentially case-sensitive; this depends on how the attribute value is handled for particular properties. たとえば、属性値で列挙型のメンバー名が宣言されている場合、その列挙型メンバーの値を返すためにメンバー名文字列を型変換する組み込みの動作では、大文字と小文字は区別されません。For example, if the attribute value declares a member name of an enumeration, the built-in behavior that type-converts a member name string to return the enumeration member value is not case-sensitive. 一方、Name プロパティの値と、Name プロパティで宣言した名前に基づきオブジェクトを操作するユーティリティ メソッドでは、名前の文字列の大文字と小文字が区別されます。In contrast, the value of the Name property, and utility methods for working with objects based on the name that the Name property declares, treat the name string as case-sensitive.

XAML 名前スコープXAML namescopes

XAML 言語では、XAML 名前スコープという概念が定義されています。The XAML language defines a concept of a XAML namescope. XAML 名前スコープの概念は、XAML 要素に適用された x:NameName の値が XAML プロセッサによってどのように扱われるか (特に名前を一意の識別子として使うスコープ) に影響します。The XAML namescope concept influences how XAML processors should treat the value of x:Name or Name applied to XAML elements, particularly the scopes in which names should be relied upon to be unique identifiers. XAML 名前スコープについては、別のトピックで詳しく説明します。「XAML 名前スコープ」をご覧ください。XAML namescopes are covered in more detail in a separate topic; see XAML namescopes.

開発プロセスでの XAML の役割The role of XAML in the development process

XAML は、アプリ開発プロセスにおいて重要な役割を果たします。XAML plays several important roles in the app development process.

  • XAML は、C#、Visual Basic、または C++/CX を使ったプログラミングでアプリの UI と UI 内の要素を宣言するための基本形式です。XAML is the primary format for declaring an app's UI and elements in that UI, if you are programming using C#, Visual Basic or C++/CX. 一般的には、プロジェクトの 1 つ以上の XAML ファイルが、アプリの初期表示される UI のページ メタファを表します。Typically at least one XAML file in your project represents a page metaphor in your app for the initially displayed UI. また、別の XAML ファイルで、ナビゲーション用 UI のための追加のページを宣言できます。Additional XAML files might declare additional pages for navigation UI. それ以外の XAML ファイルでは、リソース (テンプレート、スタイルなど) を宣言できます。Other XAML files can declare resources, such as templates or styles.
  • XAML 形式は、アプリのコントロールや UI に適用されるスタイルとテンプレートを宣言するために使われます。You use the XAML format for declaring styles and templates applied to controls and UI for an app.
  • 既存のコントロールをテンプレート化する場合や、コントロール パッケージの一部として既定のテンプレートを提供するコントロールを定義する場合などに、スタイルとテンプレートを使います。You might use styles and templates either for templating existing controls, or if you define a control that supplies a default template as part of a control package. スタイルやテンプレートを定義する際には、通常、関連する XAML を、ResourceDictionary をルートとする独立した XAML ファイルとして宣言します。When you use it to define styles and templates, the relevant XAML is often declared as a discrete XAML file with a ResourceDictionary root.
  • XAML は、アプリの UI を作成し異なるデザイナー アプリ間で UI 設計を交換することを可能にするデザイナー サポートの共通形式です。XAML is the common format for designer support of creating app UI and exchanging the UI design between different designer apps. たとえば、アプリの XAML を異なる XAML デザイン ツール (またはツール内のデザイン ウィンドウ) の間で交換することができます。Most notably, XAML for the app can be interchanged between different XAML design tools (or design windows within tools).
  • XAML で基本的な UI を定義するテクノロジは他にもあります。Several other technologies also define the basic UI in XAML. Windows ランタイムの XAML は、Windows Presentation Foundation (WPF) XAML や Microsoft Silverlight XAML と関連があり、共有される既定の XAML 名前空間用に同じ URI を使っています。In relationship to Windows Presentation Foundation (WPF) XAML and Microsoft Silverlight XAML, the XAML for Windows Runtime uses the same URI for its shared default XAML namespace. また、Windows ランタイムの XAML ボキャブラリの多くは、Silverlight や (Silverlight ほどではありませんが) WPF でも使われている XAML-for-UI ボキャブラリと共通しています。The XAML vocabulary for Windows Runtime overlaps significantly with the XAML-for-UI vocabulary also used by Silverlight and to a slightly lesser extent by WPF. そのため、XAML を使う先行技術のために定義された UI を効率的に移行することができます。Thus, XAML promotes an efficient migration pathway for UI originally defined for precursor technologies that also used XAML.
  • XAML で UI の外観を定義し、関連付けられたコード ビハインド ファイルでロジックを定義します。XAML defines the visual appearance of a UI, and an associated code-behind file defines the logic. UI 設計は、コード ビハインドのロジックに変更を加えることなく調整できます。You can adjust the UI design without making changes to the logic in code-behind. XAML は、デザイナーと開発者との間のワークフローを単純化します。XAML simplifies the workflow between designers and developers.
  • ビジュアル デザイナーとビジュアル デザイン サーフェイスの高度な機能による XAML 言語のサポートがあるため、XAML では、開発の初期段階での迅速な UI のプロトタイピングが可能になります。Because of the richness of the visual designer and design surface support for the XAML language, XAML supports rapid UI prototyping in the early development phases.

開発プロセスにおける役割によっては、XAML を使う機会がそれほどない場合もあります。Depending on your own role in the development process, you might not interact with XAML much. XAML ファイルと対話する度合いは、使っている開発環境、ツールボックスやプロパティ エディターなどの対話型のデザイン環境機能を使っているかどうか、Windows ランタイム アプリの範囲と目的によっても異なります。The degree to which you do interact with XAML files also depends on which development environment you are using, whether you use interactive design environment features such as toolboxes and property editors, and the scope and purpose of your Windows Runtime app. それでも、アプリの開発時には、テキスト エディターや XML エディターを使って要素レベルで XAML ファイルの編集を行うこともありえます。Nevertheless, it is likely that during development of the app, you will be editing a XAML file at the element level using a text or XML editor. ここに示された情報を理解することで、XAML のテキスト表現や XML 表現を正確に編集できるようになります。さらに、XAML ファイルがツール、マークアップのコンパイル処理、Windows ランタイム アプリのランタイム フェーズによって使われる際に、XAML ファイルの宣言と目的の妥当性を保持することができます。Using this info, you can confidently edit XAML in a text or XML representation and maintain the validity of that XAML file's declarations and purpose when it is consumed by tools, markup compile operations, or the run-time phase of your Windows Runtime app.

読み込みパフォーマンスを向上させるための XAML の最適化Optimize your XAML for load performance

パフォーマンスを向上させるためのベスト プラクティスを使って XAML で UI 要素を定義するためのヒントを次に示します。Here are some tips for defining UI elements in XAML using best practices for performance. これらのヒントの多くは XAML リソースの使用に関するものですが、便宜上、一般的な XAML の概要を示すこのトピックにおいても紹介します。Many of these tips relate to using XAML resources, but are listed here in the general XAML overview for convenience. XAML リソースについて詳しくは、「ResourceDictionary と XAML リソースの参照」をご覧ください。For more info about XAML resources see ResourceDictionary and XAML resource references. パフォーマンス向上のヒントについて詳しくは、パフォーマンスに悪影響を及ぼすため避ける必要のある XAML の実例も含めて、「XAML マークアップの最適化」をご覧ください。For some more tips on performance, including XAML that purposely demonstrates some of the poor performance practices that you should avoid in your XAML, see Optimize your XAML markup.

  • XAML で同じ色のブラシをよく使う場合は、その都度名前付きの色を属性値として使う代わりに、SolidColorBrush をリソースとして定義します。If you use the same color brush often in your XAML, define a SolidColorBrush as a resource rather than using a named color as an attribute value each time.
  • 複数の UI ページに同じリソースを使う場合は、各ページではなく Application.Resources にそのリソースを定義することをお勧めします。If you use the same resource on more than one UI page, consider defining it in Application.Resources rather than on each page. 逆に、1 つのページのみでリソースを使う場合は、リソースを Application.Resources に定義する代わりに、必要なページだけに定義します。Conversely, if only one page uses a resource, don't define it in Application.Resources and instead define it only for the page that needs it. これは、アプリ設計時の XAML ファクタリングと、XAML 構文解析時のパフォーマンスの両方に有効です。This is good both for XAML factoring while designing your app and for performance during XAML parsing.
  • アプリでパッケージ化するリソースについては、使われていないリソース (キーを持つ一方でそれを使うアプリ内に StaticResource 参照がないリソース) がないかどうかを調べます。For resources that your app packages, check for unused resources (a resource that has a key, but there's no StaticResource reference in your app that uses it). これらは、アプリをリリースする前に、XAML から削除します。Remove these from your XAML before you release your app.
  • デザイン リソース (MergedDictionaries) を提供する別個の XAML ファイルを使う場合は、その XAML ファイルから使われていないリソースをコメント アウトするか削除することをお勧めします。If you're using separate XAML files that provides design resources (MergedDictionaries), consider commenting or removing unused resources from these files. 複数のアプリで使っている共有 XAML や、すべてのアプリに共通するリソースを提供する共有 XAML がある場合でも、毎回 XAML リソースをパッケージ化するのはアプリであり、そのたびに XAML リソースを読み込む可能性があります。Even if you have a shared XAML starting point that you're using in more than one app or that provides common resources for all your app, it's still your app that packages the XAML resources each time, and potentially has to load them.
  • 構成に必要ない UI 要素は定義しないでください。可能な限り、既定のコントロール テンプレートを使ってください (既定のテンプレートは読み込み時のパフォーマンスが既にテストされ確認されています)。Don't define UI elements you don't need for composition, and use the default control templates whenever possible (these templates have already been tested and verified for load performance).
  • UI 要素の範囲を超えた描画を避け、Border などのコンテナーを使うようにします。Use containers such as Border rather than deliberate overdraws of UI elements. 基本的に、同じピクセルを複数回描画しないでください。Basically, don't draw the same pixel multiple times. 過剰な描画とそのテスト方法について詳しくは、DebugSettings.IsOverdrawHeatMapEnabled をご覧ください。For more info on overdraw and how to test for it, see DebugSettings.IsOverdrawHeatMapEnabled.
  • ListViewGridView には既定の項目テンプレートを使います。これらには、リスト項目が多数あるビジュアル ツリーを作成する際に発生するパフォーマンスの問題を解決する特殊な Presenter ロジックが用意されています。Use the default items templates for ListView or GridView; these have special Presenter logic that solves performance issues when building the visual tree for large numbers of list items.

XAML のデバッグDebugging XAML

XAML はマークアップ言語であるため、Microsoft Visual Studio が備えている一般的なデバッグ方法のいくつかは使うことができません。Because XAML is a markup language, some of the typical strategies for debugging within Microsoft Visual Studio are not available. たとえば、XAML ファイル内にブレークポイントを設定する方法がありません。For example, there is no way to set a breakpoint within a XAML file. ただし、アプリの開発中に、UI 定義や他の XAML マークアップを使って問題のデバッグをサポートできる方法があります。However, there are other techniques that can help you debug issues with UI definitions or other XAML markup while you're still developing your app.

XAML ファイルに問題がある場合、一般的な結果として、一部のシステムやアプリによって XAML 解析例外がスローされます。When there are problems with a XAML file, the most typical result is that some system or your app will throw a XAML parse exception. XAML 解析例外が発生した場合は必ず、XAML パーサーによって読み込まれる XAML では、有効なオブジェクト ツリーの作成に失敗します。Whenever there is a XAML parse exception, the XAML loaded by the XAML parser failed to create a valid object tree. たとえば、XAML によってアプリケーションの最初の "ページ" (ルート ビジュアルとして読み込まれます) が表される場合、XAML 解析例外は回復可能ではありません。In some cases, such as when the XAML represents the first "page" of your application that is loaded as the root visual, the XAML parse exception is not recoverable.

XAML は、Visual Studio などの IDE や XAML デザイン サーフェイスのいずれかで編集されることがあります。XAML is often edited within an IDE such as Visual Studio and one of its XAML design surfaces. Visual Studio では、編集しているときに XAML ソースに対する設計時検証やエラー チェックを行うことができます。Visual Studio can often provide design-time validation and error checking of a XAML source as you edit it. たとえば、誤った属性値を入力したときに、XAML テキスト エディターで "波線" が表示される場合があります。UI 定義の問題を確認するために、XAML コンパイル パスを待機する必要はありません。For example it might display "squiggles" in the XAML text editor as soon as you type a bad attribute value, and you won't even have to wait for a XAML compile pass to see that something's wrong with your UI definition.

アプリを実際に実行したとき、XAML 解析エラーが設計時に検出されていないと、共通言語ランタイム (CLR) によって、XamlParseException として報告されます。Once the app actually runs, if any XAML parse errors have gone undetected at design time, these are reported by the common language runtime (CLR) as a XamlParseException. 実行時の XamlParseException に関する操作について詳しくは、「C# または Visual Basic での Windows ランタイム アプリの例外処理」をご覧ください。For more info on what you might be able to do for a run-time XamlParseException, see Exception handling for Windows Runtime apps in C# or Visual Basic.

  C + を使用するアプリ/cli CX コードの特定を取得しない XamlParseExceptionします。Note  Apps that use C++/CX for code don't get the specific XamlParseException. ただし、例外のメッセージによって、エラーの原因が XAML 関連であることが明らかになります。このメッセージには、XamlParseException と同様に、XAML ファイル内の行番号などのコンテキスト情報も含まれています。But the message in the exception clarifies that the source of the error is XAML-related, and includes context info such as line numbers in a XAML file, just like XamlParseException does.

Windows ランタイム アプリのデバッグについて詳しくは、「デバッグ セッションの開始」をご覧ください。Fore more info on debugging a Windows Runtime app, see Start a debug session.