XAML 構文の詳細XAML Syntax In Detail

このトピックでは、XAML 構文の要素について説明するために使用される用語を定義します。This topic defines the terms that are used to describe the elements of XAML syntax. これらの用語は、このドキュメントの他の部分で頻繁に使用されます。WPF のドキュメントと、System.Xaml レベルでの XAML 言語サポートによって有効にされる XAML および XAML の基本的な概念を使用する他のフレームワークの両方で使用されます。These terms are used frequently throughout the remainder of this documentation, both for WPF documentation specifically and for the other frameworks that use XAML or the basic XAML concepts enabled by the XAML language support at the System.Xaml level. このトピックは、XAML の概要 (WPF) に関するトピックで説明されている基本的な用語を拡充したものです。This topic expands on the basic terminology introduced in the topic XAML Overview (WPF).

XAML 言語仕様The XAML Language Specification

ここで定義されている XAML 構文の用語は、XAML 言語仕様でも定義または参照されています。The XAML syntax terminology defined here is also defined or referenced within the XAML language specification. XAML は XML に基づく言語であり、XML 構造ルールに従うか、それを拡張しています。XAML is a language based on XML and follows or expands upon XML structural rules. 一部の用語は、XML 言語または XML ドキュメント オブジェクト モデルを説明するときに一般的に使用される用語と共通であるか、またはそれが基になっています。Some of the terminology is shared from or is based on the terminology commonly used when describing the XML language or the XML document object model.

XAML 言語仕様の詳細については、Microsoft ダウンロード センターから [MS-XAML] をダウンロードしてください。For more information about the XAML language specification, download [MS-XAML] from the Microsoft Download Center.

XAML と CLRXAML and CLR

XAML はマークアップ言語です。XAML is a markup language. 名前のとおり、共通言語ランタイム (CLR) によってランタイムを実行できるようになります。The common language runtime (CLR), as implied by its name, enables runtime execution. XAML 自体は、CLR ランタイムによって直接使用される共通言語の 1 つではありません。XAML is not by itself one of the common languages that is directly consumed by the CLR runtime. そうではなく、XAML は独自の型システムをサポートするものと考えることができます。Instead, you can think of XAML as supporting its own type system. WPF によって使用される特定の XAML 解析システムは、CLR と CLR 型システムが基になっています。The particular XAML parsing system that is used by WPF is built on the CLR and the CLR type system. XAML の型は、WPF の XAML が解析されるときに、実行時の表現をインスタンス化するために、CLR の型にマップされます。XAML types are mapped to CLR types to instantiate a run time representation when the XAML for WPF is parsed. このため、このドキュメントの構文に関する残りの部分には、CLR 型システムへの参照が含まれています。ただし、XAML 言語仕様での同等の構文の説明には含まれません。For this reason, the remainder of discussion of syntax in this document will include references to the CLR type system, even though the equivalent syntax discussions in the XAML language specification do not. (XAML 言語仕様レベルによると、XAML 型は他の任意の型システムにマップでき、それは CLR である必要はありませんが、それには別の XAML パーサーを作成して使用する必要があります)。(Per the XAML language specification level, XAML types could be mapped to any other type system, which does not have to be the CLR, but that would require the creation and use of a different XAML parser.)

型のメンバーとクラスの継承Members of Types and Class Inheritance

WPFWPF 型の XAML メンバーであるプロパティとイベントは、多くの場合、基本型から継承されます。Properties and events as they appear as XAML members of a WPFWPF type are often inherited from base types. たとえば、<Button Background="Blue" .../> について考えてみます。For example, consider this example: <Button Background="Blue" .../>. クラス定義、リフレクション結果、またはドキュメントを見ると、Background プロパティは、Button クラスで直接宣言されているプロパティではありません。The Background property is not an immediately declared property on the Button class, if you were to look at the class definition, reflection results, or the documentation. そうではなく、Background は基底クラス Control から継承されています。Instead, Background is inherited from the base Control class.

WPFWPF の XAML 要素のクラス継承動作は、XML マークアップのスキーマで適用される解釈とは大きく異なります。The class inheritance behavior of WPFWPF XAML elements is a significant departure from a schema-enforced interpretation of XML markup. クラスの継承は複雑になる可能性があります。中間の基底クラスが抽象型の場合、またはインターフェイスが関係している場合は特にそうです。Class inheritance can become complex, particularly when intermediate base classes are abstract, or when interfaces are involved. これは、DTD 形式や XSD 形式などの XML プログラミングで通常使用されるスキーマ型を使用して、XAML の要素とその使用可能な属性のセットを正確かつ完全に表現することが困難な理由の 1 つです。This is one reason that the set of XAML elements and their permissible attributes is difficult to represent accurately and completely using the schema types that are typically used for XML programming, such as DTD or XSD format. もう 1 つの理由は、XAML 言語自体の機能拡張および型マッピング機能により、許容される型とメンバーを完全かつ一意的に表現することが不可能なためです。Another reason is that extensibility and type-mapping features of the XAML language itself preclude completeness of any fixed representation of the permissible types and members.

オブジェクト要素構文Object Element Syntax

"オブジェクト要素構文" は、XML 要素を宣言することで CLR のクラスまたは構造体をインスタンス化する XAML マークアップ構文です。Object element syntax is the XAML markup syntax that instantiates a CLR class or structure by declaring an XML element. この構文は、HTML などの他のマークアップ言語の要素構文に似ています。This syntax resembles the element syntax of other markup languages such as HTML. オブジェクト要素構文は、左山かっこ (<) で始まり、インスタンス化されるクラスまたは構造体の型名が続きます。Object element syntax begins with a left angle bracket (<), followed immediately by the type name of the class or structure being instantiated. 型名の後には、0 個以上の空白を挿入できます。また、0 個以上の属性をオブジェクト要素で宣言することもできます。属性名 = "値" のペアを区切るには、1 つ以上のスペースを使用します。Zero or more spaces can follow the type name, and zero or more attributes may also be declared on the object element, with one or more spaces separating each attribute name="value" pair. 最後に、次のいずれかが満たされている必要があります。Finally, one of the following must be true:

  • 要素とタグは、スラッシュ (/) とその直後の右山かっこ (>) によって閉じられる必要があります。The element and tag must be closed by a forward slash (/) followed immediately by a right angle bracket (>).

  • 開始タグは、右山かっこ (>) によって終了する必要があります。The opening tag must be completed by a right angle bracket (>). 開始タグの後には、他のオブジェクト要素、プロパティ要素、または内部テキストを記述できます。Other object elements, property elements, or inner text, can follow the opening tag. 厳密にここに含めることができる内容については、通常、要素のオブジェクト モデルによって制限されます。Exactly what content may be contained here is typically constrained by the object model of the element. 適切な入れ子および他の開始および終了タグのペアとのバランスのため、オブジェクト要素に対応する終了タグが存在する必要もあります。The equivalent closing tag for the object element must also exist, in proper nesting and balance with other opening and closing tag pairs.

.NET によって実装される XAML には、オブジェクト要素から型、属性からプロパティまたはイベント、および XAML 名前空間から CLR 名前空間とアセンブリへのマップに関する一連の規則があります。XAML as implemented by .NET has a set of rules that map object elements into types, attributes into properties or events, and XAML namespaces to CLR namespaces plus assembly. WPF と .NET では、XAML オブジェクト要素は参照されているアセンブリで定義されている .NET 型にマップされ、属性はそれらの型のメンバーにマップされます。For WPF and .NET, XAML object elements map to .NET types as defined in referenced assemblies, and the attributes map to members of those types. XAML で CLR 型を参照する場合は、その型の継承されたメンバーにもアクセスできます。When you reference a CLR type in XAML, you have access to the inherited members of that type as well.

たとえば、次の例は、Button クラスの新しいインスタンスをインスタンス化し、Name 属性とその属性の値を指定するオブジェクト要素構文です。For example, the following example is object element syntax that instantiates a new instance of the Button class, and also specifies a Name attribute and a value for that attribute:

<Button Name="CheckoutButton"/>

次の例は、XAML コンテンツ プロパティ構文も含まれるオブジェクト要素構文です。The following example is object element syntax that also includes XAML content property syntax. 中に含まれる内部テキストは、TextBox の XAML コンテンツ プロパティ Text を設定するために使用されます。The inner text contained within will be used to set the TextBox XAML content property, Text.

<TextBox>This is a Text Box</TextBox>

コンテンツ モデルContent Models

クラスでは構文に関して XAML オブジェクト要素としての使用がサポートされている場合がありますが、その要素がアプリケーションまたはページで正しく機能するのは、コンテンツ モデルまたは要素ツリー全体の予想される位置に配置されている場合だけです。A class might support a usage as a XAML object element in terms of the syntax, but that element will only function properly in an application or page when it is placed in an expected position of an overall content model or element tree. たとえば、MenuItem は通常、Menu などの MenuBase 派生クラスの子としてのみ配置する必要があります。For example, a MenuItem should typically only be placed as a child of a MenuBase derived class such as Menu. 特定の要素のコンテンツ モデルは、XAML 要素として使用できるコントロールおよび他の WPFWPF クラスのクラス ページの解説の一部として説明されています。Content models for specific elements are documented as part of the remarks on the class pages for controls and other WPFWPF classes that can be used as XAML elements.

オブジェクト要素のプロパティProperties of Object Elements

XAML のプロパティは、さまざまな構文で設定できます。Properties in XAML are set by a variety of possible syntaxes. 特定のプロパティに使用できる構文は、設定するプロパティの基になる型システムの特性によって異なります。Which syntax can be used for a particular property will vary, based on the underlying type system characteristics of the property that you are setting.

プロパティの値を設定することにより、オブジェクトが実行時オブジェクト グラフに存在するときの機能または特性が追加されます。By setting values of properties, you add features or characteristics to objects as they exist in the run time object graph. オブジェクト要素から作成されるオブジェクトの初期状態は、パラメーターなしのコンストラクターの動作に基づきます。The initial state of the created object from a object element is based on the parameterless constructor behavior. 通常、アプリケーションでは、特定のオブジェクトの完全に既定のインスタンス以外のものを使用します。Typically, your application will use something other than a completely default instance of any given object.

属性構文 (プロパティ)Attribute Syntax (Properties)

属性構文は、既存のオブジェクト要素の属性を宣言することによってプロパティの値を設定する XAML マークアップ構文です。Attribute syntax is the XAML markup syntax that sets a value for a property by declaring an attribute on an existing object element. 属性名は、関連するオブジェクト要素の基になっているクラスのプロパティの CLR メンバー名と一致している必要があります。The attribute name must match the CLR member name of the property of the class that backs the relevant object element. 属性名の後に代入演算子 (=) を記述します。The attribute name is followed by an assignment operator (=). 属性値は、引用符で囲まれた文字列である必要があります。The attribute value must be a string enclosed within quotes.

注意

代替引用符を使用することにより、属性内でリテラルの引用符を使用できます。You can use alternating quotes to place a literal quotation mark within an attribute. たとえば、二重引用符が含まれる文字列を宣言する手段として、単一引用符を使用できます。For instance you can use single quotes as a means to declare a string that contains a double quote character within it. 単一引用符と二重引用符のどちらを使用する場合でも、属性値の文字列の開始と終了には、一致するペアを使用する必要があります。Whether you use single or double quotes, you should use a matching pair for opening and closing the attribute value string. また、特定の XAML 構文での文字制限を回避するために使用できるエスケープ シーケンスやその他の手法もあります。There are also escape sequences or other techniques available for working around character restrictions imposed by any particular XAML syntax. XML 文字エンティティと XAML」を参照してください。See XML Character Entities and XAML.

属性構文を使用して設定するには、プロパティはパブリックで、書き込み可能である必要があります。In order to be set through attribute syntax, a property must be public and must be writeable. バッキング型システムでのプロパティの値は、値型であるか、または関連するバッキング型にアクセスするときに XAML プロセッサによってインスタンス化または参照できる参照型である必要があります。The value of the property in the backing type system must be a value type, or must be a reference type that can be instantiated or referenced by a XAML processor when accessing the relevant backing type.

WPF XAML イベントの場合、属性名として参照されるイベントはパブリックであり、パブリック デリゲートを持つ必要があります。For WPF XAML events, the event that is referenced as the attribute name must be public and have a public delegate.

プロパティまたはイベントは、含む側のオブジェクト要素によってインスタンス化されるクラスまたは構造体のメンバーである必要があります。The property or event must be a member of the class or structure that is instantiated by the containing object element.

属性値の処理Processing of Attribute Values

開始と終了の引用符に含まれる文字列値は、XAML プロセッサによって処理されます。The string value contained within the opening and closing quotation marks is processed by a XAML processor. プロパティの既定の処理動作は、基になる CLR プロパティの型によって決まります。For properties, the default processing behavior is determined by the type of the underlying CLR property.

属性値は、次のいずれかの方法により、この処理順序で設定されます。The attribute value is filled by one of the following, using this processing order:

  1. XAML プロセッサで、中かっこまたは MarkupExtension から派生したオブジェクト要素が検出された場合は、値を文字列として処理するのではなく、参照されているマークアップ拡張が最初に評価され、マークアップ拡張によって返されるオブジェクトが値として使用されます。If the XAML processor encounters a curly brace, or an object element that derives from MarkupExtension, then the referenced markup extension is evaluated first rather than processing the value as a string, and the object returned by the markup extension is used as the value. 多くの場合、マークアップ拡張によって返されるオブジェクトは、既存のオブジェクトへの参照、または実行時まで評価が延期される式であり、新しくインスタンス化されたオブジェクトではありません。In many cases the object returned by a markup extension will be a reference to an existing object, or an expression that defers evaluation until run time, and is not a newly instantiated object.

  2. プロパティが属性付きの TypeConverter で宣言されている場合、またはプロパティの値の型が属性付きの TypeConverter で宣言されている場合は、属性の文字列値が変換入力として型コンバーターに送信され、コンバーターからは新しいオブジェクト インスタンスが返されます。If the property is declared with an attributed TypeConverter, or the value type of that property is declared with an attributed TypeConverter, the string value of the attribute is submitted to the type converter as a conversion input, and the converter will return a new object instance.

  3. TypeConverter がない場合は、プロパティ型への直接変換が試みられます。If there is no TypeConverter, a direct conversion to the property type is attempted. この最終的なレベルは、XAML 言語プリミティブ型間のパーサー ネイティブ値での直接変換、または列挙型の名前付き定数の名前のチェック (その場合、パーサーは一致した値にアクセスします) です。This final level is a direct conversion at the parser-native value between XAML language primitive types, or a check for the names of named constants in an enumeration (the parser then accesses the matching values).

列挙属性の値Enumeration Attribute Values

XAML の列挙は、本質的に XAML パーサーによって処理され、列挙型のメンバーは、列挙型の名前付き定数の 1 つの文字列名を指定することによって指定する必要があります。Enumerations in XAML are processed intrinsically by XAML parsers, and the members of an enumeration should be specified by specifying the string name of one of the enumeration's named constants.

フラグ以外の列挙値に対するネイティブな動作では、属性値の文字列が処理されて、列挙値のいずれかに解決されます。For nonflag enumeration values, the native behavior is to process the string of an attribute value and resolve it to one of the enumeration values. コードでのように <列挙型>.<> の形式で列挙型を指定することはありません。You do not specify the enumeration in the format Enumeration.Value, as you do in code. 代わりに "" だけを指定し、"列挙型" は設定するプロパティの型によって推論されます。Instead, you specify only Value, and Enumeration is inferred by the type of the property you are setting. <列挙型>.<> の形式で属性を指定した場合は、正しく解決されません。If you specify an attribute in the Enumeration.Value form, it will not resolve correctly.

フラグ列挙型の動作は、Enum.Parse メソッドに基づきます。For flagwise enumerations, the behavior is based on the Enum.Parse method. 各値をコンマで区切ることにより、フラグ列挙型に複数の値を指定できます。You can specify multiple values for a flagwise enumeration by separating each value with a comma. ただし、フラグではない列挙値を組み合わせることはできません。However, you cannot combine enumeration values that are not flagwise. たとえば、コンマ構文を使用して、非フラグ列挙型の複数の条件に対して動作する Trigger を作成することはできません。For instance, you cannot use the comma syntax to attempt to create a Trigger that acts on multiple conditions of a nonflag enumeration:

<!--This will not compile, because Visibility is not a flagwise enumeration.-->  
...  
<Trigger Property="Visibility" Value="Collapsed,Hidden">  
  <Setter ... />  
</Trigger>  
...  

XAML で設定可能な属性をサポートするフラグ列挙型は、WPF ではほとんど使用されません。Flagwise enumerations that support attributes that are settable in XAML are rare in WPF. ただし、そのような列挙型の 1 つは StyleSimulations です。However, one such enumeration is StyleSimulations. たとえば、コンマ区切りのフラグ属性構文を使用して、Glyphs クラスの解説に記載されている例を変更することができます。StyleSimulations = "BoldSimulation"StyleSimulations = "BoldSimulation,ItalicSimulation" にすることができます。You could, for instance, use the comma-delimited flagwise attribute syntax to modify the example provided in the Remarks for the Glyphs class; StyleSimulations = "BoldSimulation" could become StyleSimulations = "BoldSimulation,ItalicSimulation". KeyBinding.Modifiers は、複数の列挙値を指定できるもう 1 つのプロパティです。KeyBinding.Modifiers is another property where more than one enumeration value can be specified. ただし、このプロパティは、ModifierKeys 列挙型で独自の型コンバーターがサポートされているため、特別なケースになります。However, this property happens to be a special case, because the ModifierKeys enumeration supports its own type converter. 修飾子の型コンバーターでは、コンマ (,) ではなくプラス記号 (+) が区切り記号として使用されます。The type converter for modifiers uses a plus sign (+) as a delimiter rather than a comma (,). この変換では、"Ctrl + Alt" など、Microsoft Windows プログラミングでキーの組み合わせを表す従来の構文がサポートされています。This conversion supports the more traditional syntax to represent key combinations in Microsoft Windows programming, such as "Ctrl+Alt".

プロパティとイベント メンバー名の参照Properties and Event Member Name References

属性を指定するときは、含む側のオブジェクト要素に対してインスタンス化した CLR 型のメンバーとして存在する任意のプロパティまたはイベントを参照できます。When specifying an attribute, you can reference any property or event that exists as a member of the CLR type you instantiated for the containing object element.

または、含む側のオブジェクト要素とは無関係に、添付プロパティまたは添付イベントを参照できます。Or, you can reference an attached property or attached event, independent of the containing object element. (添付プロパティについては、次のセクションで説明します)。(Attached properties are discussed in an upcoming section.)

<型名>.<イベント> という部分修飾名を使用して、既定の名前空間でアクセスできる任意のオブジェクトから、任意のイベントを指定することもできます。この構文では、子要素からのイベント ルーティングをハンドラーで処理することが想定されているにも関わらず、親要素のメンバー テーブルにそのイベントがない場合の、ルーティング イベントに対するハンドラーのアタッチがサポートされています。You can also name any event from any object that is accessible through the default namespace by using a typeName.event partially qualified name; this syntax supports attaching handlers for routed events where the handler is intended to handle events routing from child elements, but the parent element does not also have that event in its members table. この構文は添付イベントの構文に似ていますが、ここでのイベントは添付イベントではありません。This syntax resembles an attached event syntax, but the event here is not a true attached event. この場合は、修飾名を持つイベントを参照しています。Instead, you are referencing an event with a qualified name. 詳細については、「ルーティング イベントの概要」を参照してください。For more information, see Routed Events Overview.

一部のシナリオでは、属性の値として属性名ではなくプロパティ名が指定されることがあります。For some scenarios, property names are sometimes provided as the value of an attribute, rather than the attribute name. そのプロパティ名には、<所有者の型>.<依存プロパティ名> の形式で指定されたプロパティなど、修飾子が含まれる場合もあります。That property name can also include qualifiers, such as the property specified in the form ownerType.dependencyPropertyName. このシナリオは、XAML でスタイルやテンプレートを作成する場合によく見られます。This scenario is common when writing styles or templates in XAML. 属性値として指定されたプロパティ名の処理規則は異なり、設定されているプロパティの型、または特定の WPF サブシステムの動作によって管理されます。The processing rules for property names provided as an attribute value are different, and are governed by the type of the property being set or by the behaviors of particular WPF subsystems. 詳細については、「スタイルとテンプレート」を参照してください。For details, see Styling and Templating.

プロパティ名のもう 1 つの使用方法は、属性値でプロパティとプロパティの関係が記述されている場合です。Another usage for property names is when an attribute value describes a property-property relationship. この機能は、データ バインディングとストーリーボード ターゲットに対して使用され、PropertyPath クラスとその型コンバーターによって有効になります。This feature is used for data binding and for storyboard targets, and is enabled by the PropertyPath class and its type converter. 参照セマンティクスの詳細については、「PropertyPath の XAML 構文」を参照してください。For a more complete description of the lookup semantics, see PropertyPath XAML Syntax.

プロパティ要素の構文Property Element Syntax

"プロパティ要素の構文" は、要素の基本的な XML 構文規則とは少し異なる構文です。Property element syntax is a syntax that diverges somewhat from the basic XML syntax rules for elements. XML では、属性の値は事実上は文字列であり、唯一可能なバリエーションは、使用される文字列エンコード形式です。In XML, the value of an attribute is a de facto string, with the only possible variation being which string encoding format is being used. XAML では、プロパティの値として他のオブジェクト要素を割り当てることができます。In XAML, you can assign other object elements to be the value of a property. この機能は、プロパティ要素の構文によって有効になります。This capability is enabled by the property element syntax. プロパティは、要素タグ内の属性として指定されるのではなく、<要素型名>.<プロパティ名> という形式の開始要素タグを使用して指定され、プロパティの値がその中で指定されて、プロパティ要素が閉じられます。Instead of the property being specified as an attribute within the element tag, the property is specified using an opening element tag in elementTypeName.propertyName form, the value of the property is specified within, and then the property element is closed.

具体的には、構文は左山かっこ (<) で始まり、その直後に、プロパティ要素の構文が含まれているクラスまたは構造体の型名が続きます。Specifically, the syntax begins with a left angle bracket (<), followed immediately by the type name of the class or structure that the property element syntax is contained within. それ以降は、1 つのドット (.)、プロパティの名前、右山かっこ (>) の順になります。This is followed immediately by a single dot (.), then by the name of a property, then by a right angle bracket (>). 属性構文と同様に、そのプロパティは、指定された型の宣言されたパブリック メンバー内に存在する必要があります。As with attribute syntax, that property must exist within the declared public members of the specified type. プロパティに割り当てられる値は、プロパティ要素内に格納されています。The value to be assigned to the property is contained within the property element. プロパティ要素の構文では値として指定されたオブジェクトを処理することが想定されているため、通常、値は 1 つ以上のオブジェクト要素として指定します。Typically, the value is given as one or more object elements, because specifying objects as values is the scenario that property element syntax is intended to address. 最後に、同じ <要素型名>.<プロパティ名> の組み合わせを指定する同等の終了タグを指定し、適切な入れ子および他の要素タグとのバランスにする必要があります。Finally, an equivalent closing tag specifying the same elementTypeName.propertyName combination must be provided, in proper nesting and balance with other element tags.

たとえば、次に示すのは、ButtonContextMenu プロパティに対するプロパティ要素の構文です。For example, the following is property element syntax for the ContextMenu property of a Button.

<Button>
  <Button.ContextMenu>
    <ContextMenu>
      <MenuItem Header="1">First item</MenuItem>
      <MenuItem Header="2">Second item</MenuItem>
    </ContextMenu>
  </Button.ContextMenu>
  Right-click me!</Button>

また、指定されるプロパティの型が String などのプリミティブ値の型である場合、または名前が指定された列挙型である場合は、プロパティ要素内の値を内部テキストとして指定することもできます。The value within a property element can also be given as inner text, in cases where the property type being specified is a primitive value type, such as String, or an enumeration where a name is specified. これらの 2 つの使用方法は、いずれの場合もさらに単純な属性構文を使用できるため、あまり一般的ではありません。These two usages are somewhat uncommon, because each of these cases could also use a simpler attribute syntax. 文字列でプロパティ要素を指定する 1 つのシナリオは、XAML コンテンツ プロパティではなくても、UI テキストの表現に使用され、ラインフィードなどの特定の空白文字要素をその UI テキストで表示する必要があるプロパティの場合です。One scenario for filling a property element with a string is for properties that are not the XAML content property but still are used for representation of UI text, and particular white-space elements such as linefeeds are required to appear in that UI text. 属性の構文では改行を保持できませんが、プロパティ要素の構文では、重要な空白の保持がアクティブになっている場合は保持できます (詳細については、「XAML での空白の処理」を参照してください)。Attribute syntax cannot preserve linefeeds, but property element syntax can, so long as significant white-space preservation is active (for details, see White space processing in XAML). もう 1 つのシナリオは、x:Uid ディレクティブをプロパティ要素に適用し、その中の値を、WPF 出力 BAML または他の手法でローカライズする必要がある値としてマークできるようにする場合です。Another scenario is so that x:Uid Directive can be applied to the property element and thus mark the value within as a value that should be localized in the WPF output BAML or by other techniques.

プロパティ要素は、WPF 論理ツリーでは表されません。A property element is not represented in the WPF logical tree. プロパティ要素は、プロパティを設定するための特定の構文であり、その基になるインスタンスまたはオブジェクトがある要素ではありません。A property element is just a particular syntax for setting a property, and is not an element that has an instance or object backing it. (論理ツリーの概念の詳細については、「WPF のツリー」を参照してください)。(For details on the logical tree concept, see Trees in WPF.)

属性とプロパティ要素の両方の構文がサポートされているプロパティの場合は、通常、2 つの構文は同じ結果になりますが、空白文字の処理などの微妙な点は構文によって多少異なります。For properties where both attribute and property element syntax are supported, the two syntaxes generally have the same result, although subtleties such as white-space handling can vary slightly between syntaxes.

コレクションの構文Collection Syntax

XAML の仕様では、値の型がコレクションであるプロパティを XAML プロセッサの実装で識別する必要があります。The XAML specification requires XAML processor implementations to identify properties where the value type is a collection. .NET での一般的な XAML プロセッサの実装は、マネージド コードと CLR に基づいており、次のいずれかを使用してコレクション型を識別します。The general XAML processor implementation in .NET is based on managed code and the CLR, and it identifies collection types through one of the following:

プロパティの型がコレクションである場合、推論されるコレクション型を、マークアップでオブジェクト要素として指定する必要はありません。If the type of a property is a collection, then the inferred collection type does not need to be specified in the markup as an object element. 代わりに、コレクションの項目になることが予想される要素を、プロパティ要素の 1 つ以上の子要素として指定します。Instead, the elements that are intended to become the items in the collection are specified as one or more child elements of the property element. そのような各項目は、読み込み中にオブジェクトに対して評価され、暗黙的なコレクションの Add メソッドを呼び出すことによってコレクションに追加されます。Each such item is evaluated to an object during loading and added to the collection by calling the Add method of the implied collection. たとえば、StyleTriggers プロパティは特殊なコレクション型 TriggerCollection になり、その型では IList が実装されています。For example, the Triggers property of Style takes the specialized collection type TriggerCollection, which implements IList. マークアップで TriggerCollection オブジェクト要素をインスタンス化する必要はありません。It is not necessary to instantiate a TriggerCollection object element in the markup. 代わりに、1 つ以上の Trigger 項目を Style.Triggers プロパティ要素内の要素として指定します。ここで、Trigger (または派生クラス) は、厳密に型指定された暗黙の TriggerCollection に対する項目型として想定される型です。Instead, you specify one or more Trigger items as elements within the Style.Triggers property element, where Trigger (or a derived class) is the type expected as the item type for the strongly typed and implicit TriggerCollection.

<Style x:Key="SpecialButton" TargetType="{x:Type Button}">
  <Style.Triggers>
    <Trigger Property="Button.IsMouseOver" Value="true">
      <Setter Property = "Background" Value="Red"/>
    </Trigger>
    <Trigger Property="Button.IsPressed" Value="true">
      <Setter Property = "Foreground" Value="Green"/>
    </Trigger>
  </Style.Triggers>
</Style>

プロパティは、コレクション型と、その型および派生型に対する XAML コンテンツ プロパティの両方にすることができます。詳細については、このトピックの次のセクションで説明します。A property may be both a collection type and the XAML content property for that type and derived types, which is discussed in the next section of this topic.

暗黙的なコレクション要素では、マークアップに要素として出現しない場合でも、論理ツリー表現にメンバーが作成されます。An implicit collection element creates a member in the logical tree representation, even though it does not appear in the markup as an element. 通常、親の型のコンストラクターでは、そのプロパティの 1 つであるコレクションのインスタンス化が実行され、初期状態が空のコレクションがオブジェクト ツリーの一部になります。Usually the constructor of the parent type performs the instantiation for the collection that is one of its properties, and the initially empty collection becomes part of the object tree.

注意

リストとディクショナリのジェネリック インターフェイス (IList<T> および IDictionary<TKey,TValue>) は、コレクションの検出に対してはサポートされていません。The generic list and dictionary interfaces (IList<T> and IDictionary<TKey,TValue>) are not supported for collection detection. ただし、List<T> を基底クラスとして使用するか (IList が直接実装されているため)、Dictionary<TKey,TValue> を基底クラスとして使用すること (IDictionary が直接実装されているため) ができます。However, you can use the List<T> class as a base class, because it implements IList directly, or Dictionary<TKey,TValue> as a base class, because it implements IDictionary directly.

コレクション型に関する .NET のリファレンス ページでは、コレクションのオブジェクト要素を意図的に省略したこの構文が、XAML 構文のセクションで暗黙のコレクション構文として示されていることがあります。In the .NET Reference pages for collection types, this syntax with the deliberate omission of the object element for a collection is occasionally noted in the XAML syntax sections as Implicit Collection Syntax.

ルート要素を除き、別の要素の子要素として入れ子になっている XAML ファイル内のすべてのオブジェクト要素は、実際には、その親要素の暗黙的なコレクション プロパティのメンバー、または親要素の XAML コンテンツ プロパティの値を指定する要素の、どちらか一方または両方です (XAML コンテンツ プロパティについては、次のセクションで説明します)。With the exception of the root element, every object element in a XAML file that is nested as a child element of another element is really an element that is one or both of the following cases: a member of an implicit collection property of its parent element, or an element that specifies the value of the XAML content property for the parent element (XAML content properties will be discussed in an upcoming section). つまり、マークアップ ページでの親要素と子要素の関係は、実際には、ルートに 1 つのオブジェクトがあり、ルートの下にあるすべてのオブジェクト要素は、親のプロパティ値を提供する単一のインスタンスであるか、または親のコレクション型プロパティ値でもあるコレクション内の項目の 1 つです。In other words, the relationship of parent elements and child elements in a markup page is really a single object at the root, and every object element beneath the root is either a single instance that provides a property value of the parent, or one of the items within a collection that is also a collection-type property value of the parent. この単一ルートの概念は XML に共通しており、多くの場合、Load などの XAML を読み込む API の動作で強化されます。This single-root concept is common with XML, and is frequently reinforced in the behavior of APIs that load XAML such as Load.

次に示すのは、明示的に指定されているコレクション (GradientStopCollection) に対するオブジェクト要素の構文の例です。The following example is a syntax with the object element for a collection (GradientStopCollection) specified explicitly.

<LinearGradientBrush>  
  <LinearGradientBrush.GradientStops>  
    <GradientStopCollection>  
      <GradientStop Offset="0.0" Color="Red" />  
      <GradientStop Offset="1.0" Color="Blue" />  
    </GradientStopCollection>  
  </LinearGradientBrush.GradientStops>  
</LinearGradientBrush>  

コレクションを明示的に宣言することが常に可能なわけではないことに注意してください。Note that it is not always possible to explicitly declare the collection. たとえば、前に示した Triggers の例で TriggerCollection を明示的に宣言しようとすると、失敗します。For instance, attempting to declare TriggerCollection explicitly in the previously shown Triggers example would fail. コレクションを明示的に宣言するには、コレクション クラスでパラメーターなしのコンストラクターがサポートされていて、TriggerCollection にパラメーターなしのコンストラクターが存在していない必要があります。Explicitly declaring the collection requires that the collection class must support a parameterless constructor, and TriggerCollection does not have a parameterless constructor.

XAML コンテンツのプロパティXAML Content Properties

XAML コンテンツの構文は、クラス宣言の一部として ContentPropertyAttribute が指定されているクラスでのみ有効な構文です。XAML content syntax is a syntax that is only enabled on classes that specify the ContentPropertyAttribute as part of their class declaration. ContentPropertyAttribute では、その型の要素 (派生クラスを含む) に対するコンテンツ プロパティであるプロパティ名が参照されます。The ContentPropertyAttribute references the property name that is the content property for that type of element (including derived classes). XAML プロセッサによって処理される場合、オブジェクト要素の開始タグと終了タグの間にある子要素または内部テキストは、そのオブジェクトの XAML コンテンツ プロパティの値として割り当てられます。When processed by a XAML processor, any child elements or inner text that are found between the opening and closing tags of the object element will be assigned to be the value of the XAML content property for that object. コンテンツ プロパティに対して明示的なプロパティ要素を指定することは許可されていますが、一般に、.NET リファレンスの XAML 構文のセクションでは、この使用方法は示されていません。You are permitted to specify explicit property elements for the content property, but this usage is not generally shown in the XAML syntax sections in the .NET reference. 明示的で詳細な手法は、マークアップのわかりやすさやマークアップのスタイルに関して場合によっては価値がありますが、通常、コンテンツ プロパティの目的は、直感的に親子として関連付けられる要素を直接入れ子にできるように、マークアップを効率化することです。The explicit/verbose technique has occasional value for markup clarity or as a matter of markup style, but usually the intent of a content property is to streamline the markup so that elements that are intuitively related as parent-child can be nested directly. 要素の他のプロパティに対するプロパティ要素タグは、XAML 言語の厳密な定義では "コンテンツ" として割り当てられません。これらは、XAML パーサーの処理順序でそれより前に処理され、"コンテンツ" とは見なされません。Property element tags for other properties on an element are not assigned as "content" per a strict XAML language definition; they are processed previously in the XAML parser's processing order and are not considered to be "content".

XAML コンテンツ プロパティの値は連続している必要があるXAML Content Property Values Must Be Contiguous

XAML コンテンツ プロパティの値は、そのオブジェクト要素の他のプロパティ要素の完全に前または完全に後のいずれかに指定する必要があります。The value of a XAML content property must be given either entirely before or entirely after any other property elements on that object element. これは、XAML コンテンツ プロパティの値が文字列として指定されているか、または 1 つ以上のオブジェクトとして指定されているに関わらず当てはまります。This is true whether the value of a XAML content property is specified as a string, or as one or more objects. たとえば、次のようなマークアップは解析されません。For example, the following markup does not parse:

<Button>I am a
  <Button.Background>Blue</Button.Background>  
  blue button</Button>  

コンテンツ プロパティのプロパティ要素構文を使用してこの構文が明示的に作成されている場合、コンテンツ プロパティが 2 回設定されるため、これは基本的に無効です。This is illegal essentially because if this syntax were made explicit by using property element syntax for the content property, then the content property would be set twice:

<Button>  
  <Button.Content>I am a </Button.Content>  
  <Button.Background>Blue</Button.Background>  
  <Button.Content> blue button</Button.Content>  
</Button>  

同じように無効な例は、コンテンツ プロパティがコレクションであり、子要素とプロパティ要素が混在している場合です。A similarly illegal example is if the content property is a collection, and child elements are interspersed with property elements:

<StackPanel>  
  <Button>This example</Button>  
  <StackPanel.Resources>  
    <SolidColorBrush x:Key="BlueBrush" Color="Blue"/>  
  </StackPanel.Resources>  
  <Button>... is illegal XAML</Button>  
</StackPanel>  

コンテンツ プロパティとコレクション構文の組み合わせContent Properties and Collection Syntax Combined

複数のオブジェクト要素をコンテンツとして受け入れるには、コンテンツ プロパティの型が明示的なコレクション型である必要があります。In order to accept more than a single object element as content, the type of the content property must specifically be a collection type. コレクション型に対するプロパティ要素の構文と同様に、XAML プロセッサではコレクション型である型を識別する必要があります。Similar to property element syntax for collection types, a XAML processor must identify types that are collection types. 要素に XAML コンテンツ プロパティがあり、XAML コンテンツ プロパティの型がコレクションである場合は、暗黙的なコレクション型をオブジェクト要素としてマークアップで指定する必要はなく、XAML コンテンツ プロパティをプロパティ要素として指定する必要もありません。If an element has a XAML content property and the type of the XAML content property is a collection, then the implied collection type does not need to be specified in the markup as an object element and the XAML content property does not need to be specified as a property element. そのため、マークアップの明白なコンテンツ モデルでは、複数の子要素をコンテンツとして割り当てることができます。Therefore the apparent content model in the markup can now have more than one child element assigned as the content. Panel 派生クラスのコンテンツ構文を次に示します。The following is content syntax for a Panel derived class. すべての Panel 派生クラスでは、XAML コンテンツ プロパティは Children として設定され、これには UIElementCollection 型の値が必要です。All Panel derived classes establish the XAML content property to be Children, which requires a value of type UIElementCollection.

<Page
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  >
  <StackPanel>
    <Button>Button 1</Button>
    <Button>Button 2</Button>
    <Button>Button 3</Button>
  </StackPanel>
</Page>

マークアップには Children のプロパティ要素も UIElementCollection の要素も必要ないことに注意してください。Note that neither the property element for Children nor the element for the UIElementCollection is required in the markup. これは XAML の設計機能であり、これにより、UIUI を定義する再帰的包含要素が、プロパティ要素タグやコレクション オブジェクトを介在させることなく、直接的な親子要素関係を持つ入れ子になった要素のツリーとして表現されます。This is a design feature of XAML so that recursively contained elements that define a UIUI are more intuitively represented as a tree of nested elements with immediate parent-child element relationships, without intervening property element tags or collection objects. 実際には、設計上、UIElementCollection をマークアップでオブジェクト要素として明示的に指定することはできません。In fact, UIElementCollection cannot be specified explicitly in markup as an object element, by design. 唯一の用途が暗黙のコレクションである UIElementCollection では、パラメーターなしのパブリック コンストラクターは公開されず、オブジェクト要素としてインスタンス化することはできません。Because its only intended use is as an implicit collection, UIElementCollection does not expose a public parameterless constructor and thus cannot be instantiated as an object element.

コンテンツ プロパティがあるオブジェクトでのプロパティ要素とオブジェクト要素の混合Mixing Property Elements and Object Elements in an Object with a Content Property

XAML の仕様では、オブジェクト要素内の XAML コンテンツ プロパティを格納するために使用されるオブジェクト要素は連続している必要があり、混合されていてはならない、ということを XAML プロセッサで適用できることが宣言されています。The XAML specification declares that a XAML processor can enforce that object elements that are used to fill the XAML content property within an object element must be contiguous, and must not be mixed. プロパティ要素とコンテンツの混合に対するこの制限は、WPFWPF の XAML プロセッサによって適用されます。This restriction against mixing property elements and content is enforced by the WPFWPF XAML processors.

オブジェクト要素内の最初の即時マークアップとして、子オブジェクト要素を指定することができます。You can have a child object element as the first immediate markup within an object element. その後、プロパティ要素を導入できます。Then you can introduce property elements. または、1 つ以上のプロパティ要素を指定し、次にコンテンツを指定し、さらにプロパティ要素を指定することもできます。Or, you can specify one or more property elements, then content, then more property elements. ただし、コンテンツの後でプロパティ要素を指定したら、それ以上コンテンツを指定することはできず、追加できるのはプロパティ要素だけです。But once a property element follows content, you cannot introduce any further content, you can only add property elements.

このコンテンツとプロパティ要素の順序に関する要件は、コンテンツとして使用される内部テキストには適用されません。This content / property element order requirement does not apply to inner text used as content. ただし、プロパティ要素と内部テキストが混在している場合、大きな空白をマークアップで視覚的に検出するのは困難であるため、内部テキストを連続させるのは、やはり適切なマークアップ スタイルです。However, it is still a good markup style to keep inner text contiguous, because significant white space will be difficult to detect visually in the markup if property elements are interspersed with inner text.

XAML 名前空間XAML Namespaces

これまでの構文の例では、既定の XAML 名前空間以外の XAML 名前空間は指定されていません。None of the preceding syntax examples specified a XAML namespace other than the default XAML namespace. 一般的な WPFWPF アプリケーションでは、WPFWPF 名前空間が既定の XAML 名前空間として指定されます。In typical WPFWPF applications, the default XAML namespace is specified to be the WPFWPF namespace. 既定の XAML 名前空間以外の XAML 名前空間を指定した場合でも、同様の構文を使用できます。You can specify XAML namespaces other than the default XAML namespace and still use similar syntax. ただし、その場合は、既定の XAML 名前空間内でアクセスできないクラスの名前を指定するすべての場所で、そのクラス名の前に、対応する CLR 名前空間にマップされる XAML 名前空間のプレフィックスを付ける必要があります。But then, anywhere where a class is named that is not accessible within the default XAML namespace, that class name must be preceded with the prefix of the XAML namespace as mapped to the corresponding CLR namespace. たとえば、<custom:Example/> は、Example クラスのインスタンスをインスタンス化するためのオブジェクト要素構文です。そのクラス (および場合によっては、バッキング型を含む外部アセンブリ情報) を含む CLR 名前空間は、これより前に custom プレフィックスにマップされています。For example, <custom:Example/> is object element syntax to instantiate an instance of the Example class, where the CLR namespace containing that class (and possibly the external assembly information that contains backing types) was previously mapped to the custom prefix.

XAML 名前空間の詳細については、「XAML 名前空間および WPF XAML の名前空間の割り当て」を参照してください。For more information about XAML namespaces, see XAML Namespaces and Namespace Mapping for WPF XAML.

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

XAML で定義されているマークアップ拡張のプログラミング エンティティを使用すると、文字列属性値またはオブジェクト要素の通常の XAML プロセッサ処理をエスケープして、処理をバッキング クラスに延期することができます。XAML defines a markup extension programming entity that enables an escape from the normal XAML processor handling of string attribute values or object elements, and defers the processing to a backing class. 属性構文を使用するときに XAML プロセッサに対してマークアップ拡張を示す文字は左中かっこ ({) で、その後に右中かっこ (}) 以外の任意の文字が続きます。The character that identifies a markup extension to a XAML processor when using attribute syntax is the opening curly brace ({), followed by any character other than a closing curly brace (}). 左中かっこの後の最初の文字列では、特定の拡張機能の動作を提供するクラスを参照する必要があります。部分文字列 "Extension" が真のクラス名の一部である場合、参照ではその部分文字列を省略できます。The first string following the opening curly brace must reference the class that provides the particular extension behavior, where the reference may omit the substring "Extension" if that substring is part of the true class name. その後には 1 つのスペースを使用でき、それ以降は、右中かっこが検出されるまで、各文字が拡張機能の実装により入力として使用されます。Thereafter, a single space may appear, and then each succeeding character is used as input by the extension implementation, up until the closing curly brace is encountered.

.NET XAML の実装では、WPFWPF および他のフレームワークやテクノロジによってサポートされているすべてのマークアップ拡張の基底として、MarkupExtension 抽象クラスが使用されます。The .NET XAML implementation uses the MarkupExtension abstract class as the basis for all of the markup extensions supported by WPFWPF as well as other frameworks or technologies. WPFWPF で明示的に実装されているマークアップ拡張の目的は、多くの場合、他の既存のオブジェクトを参照する手段を提供すること、または実行時に評価されるオブジェクトへの遅延参照を行うことです。The markup extensions that WPFWPF specifically implements are often intended to provide a means to reference other existing objects, or to make deferred references to objects that will be evaluated at run time. たとえば、特定のプロパティが通常受け取る値の代わりに {Binding} マークアップ拡張を指定することにより、簡単な WPF データ バインディングが実現されます。For example, a simple WPF data binding is accomplished by specifying the {Binding} markup extension in place of the value that a particular property would ordinarily take. WPF マークアップ拡張の多くでは、通常は属性構文を使用できない場所で、プロパティに対して属性構文を使用できます。Many of the WPF markup extensions enable an attribute syntax for properties where an attribute syntax would not otherwise be possible. たとえば、Style オブジェクトは、入れ子になった一連のオブジェクトとプロパティが含まれる比較的複雑な型です。For example, a Style object is a relatively complex type that contains a nested series of objects and properties. WPF のスタイルは、通常、ResourceDictionary のリソースとして定義された後、リソースを要求する 2 つの WPF マークアップ拡張のいずれかを使用して参照されます。Styles in WPF are typically defined as a resource in a ResourceDictionary, and then referenced through one of the two WPF markup extensions that request a resource. マークアップ拡張では、プロパティ値の評価がリソース参照まで延期され、次の例に示すように、属性構文で Style 型を使用して Style プロパティの値を提供できます。The markup extension defers the evaluation of the property value to a resource lookup and enables providing the value of the Style property, taking type Style, in attribute syntax as in the following example:

<Button Style="{StaticResource MyStyle}">My button</Button>

ここで、StaticResource は、マークアップ拡張の実装を提供する StaticResourceExtension クラスを示します。Here, StaticResource identifies the StaticResourceExtension class providing the markup extension implementation. 次の文字列 MyStyle は、既定以外の StaticResourceExtension コンストラクターに対する入力として使用されます。この場合、拡張文字列から取得されるパラメーターでは、要求される ResourceKey が宣言されています。The next string MyStyle is used as the input for the non-default StaticResourceExtension constructor, where the parameter as taken from the extension string declares the requested ResourceKey. MyStyle は、リソースとして定義されている Stylex:Key 値であると想定されます。MyStyle is expected to be the x:Key value of a Style defined as a resource. StaticResource マークアップ拡張を使用すると、読み込み時に静的リソース参照ロジックを使用して、Style プロパティ値を提供するためにリソースを使用することが要求されます。The StaticResource Markup Extension usage requests that the resource be used to provide the Style property value through static resource lookup logic at load time.

マークアップ拡張機能の詳細については、 「マークアップ拡張機能と WPF XAML」を参照してください。For more information about markup extensions, see Markup Extensions and WPF XAML. 一般的な .NET XAML の実装で有効になるマークアップ拡張と他の XAML プログラミング機能のリファレンスについては、「XAML 名前空間 (x:) 言語機能」を参照してください。For a reference of markup extensions and other XAML programming features enabled in the general .NET XAML implementation, see XAML Namespace (x:) Language Features. WPF 固有のマークアップ拡張については、「WPF XAML 拡張機能」を参照してください。For WPF-specific markup extensions, see WPF XAML Extensions.

アタッチされるプロパティAttached Properties

添付プロパティは XAML で導入されたプログラミング概念であり、プロパティを特定の型で所有および定義しながら、任意の要素の属性またはプロパティ要素として設定できます。Attached properties are a programming concept introduced in XAML whereby properties can be owned and defined by a particular type, but set as attributes or property elements on any element. 添付プロパティで想定されている主なシナリオは、すべての要素で広範にオブジェクト モデルを共有する必要なしに、マークアップ構造内の子要素で、親要素に情報を報告できるようにすることです。The primary scenario that attached properties are intended for is to enable child elements in a markup structure to report information to a parent element without requiring an extensively shared object model across all elements. 逆に、親要素で添付プロパティを使用すると、子要素に情報を報告できます。Conversely, attached properties can be used by parent elements to report information to child elements. 添付プロパティの目的と、独自の添付プロパティを作成する方法の詳細については、「添付プロパティの概要」を参照してください。For more information on the purpose of attached properties and how to create your own attached properties, see Attached Properties Overview.

添付プロパティで使用する構文は、<型名>.<プロパティ名> の組み合わせをやはり指定する点では、プロパティ要素の構文と一見似ています。Attached properties use a syntax that superficially resembles property element syntax, in that you also specify a typeName.propertyName combination. 次の 2 つの重要な違いがあります。There are two important differences:

  • 属性構文を使用して添付プロパティを設定する場合でも、<型名>.<プロパティ名> の組み合わせを使用できます。You can use the typeName.propertyName combination even when setting an attached property through attribute syntax. 属性構文でプロパティ名を修飾する必要があるのは、添付プロパティの場合だけです。Attached properties are the only case where qualifying the property name is a requirement in an attribute syntax.

  • プロパティ要素構文を添付プロパティに対して使用することもできます。You can also use property element syntax for attached properties. ただし、一般的なプロパティ要素構文で指定する <型名> は、プロパティ要素が含まれるオブジェクト要素です。However, for typical property element syntax, the typeName you specify is the object element that contains the property element. 添付プロパティを参照している場合の <型名> は、添付プロパティが定義されているクラスであり、それを含んでいるオブジェクト要素ではありません。If you are referring to an attached property, then the typeName is the class that defines the attached property, not the containing object element.

アタッチされるイベントAttached Events

添付イベントは、XAML で導入されたもう 1 つのプログラミング概念であり、特定の型でイベントを定義しながら、任意のオブジェクト要素にハンドラーを添付できます。Attached events are another programming concept introduced in XAML where events can be defined by a specific type, but handlers may be attached on any object element. WOF の実装では、多くの場合、添付イベントが定義される型は、サービスが定義されている静的な型であり、それらの添付イベントは、サービスを公開する型のルーティング イベント エイリアスによって公開されることがあります。In the WOF implementation, often the type that defines an attached event is a static type that defines a service, and sometimes those attached events are exposed by a routed event alias in types that expose the service. 添付イベントのハンドラーは、属性の構文によって指定されます。Handlers for attached events are specified through attribute syntax. 添付イベントと同様に、属性構文も添付イベントで <型名>.<イベント名> を使用できるように拡張されています。ここで、<型名> は添付イベントのインフラストラクチャに対して Add および Remove イベント ハンドラー アクセサーを提供するクラスであり、<イベント名> はイベントの名前です。As with attached events, the attribute syntax is expanded for attached events to allow a typeName.eventName usage, where typeName is the class that provides Add and Remove event handler accessors for the attached event infrastructure, and eventName is the event name.

XAML ルート要素の構造Anatomy of a XAML Root Element

次の表は、一般的な XAML ルート要素の内容です。ルート要素の特定の属性が示されています。The following table shows a typical XAML root element broken down, showing the specific attributes of a root element:

<Page ルート要素のオブジェクト要素の開始Opening object element of the root element
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 既定の (WPFWPF) XAML 名前空間The default (WPFWPF) XAML namespace
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" XAML 言語の XAML 名前空間The XAML language XAML namespace
x:Class="ExampleNamespace.ExampleCode" 部分クラスに対して定義されているコードビハインドにマークアップを接続する部分クラスの宣言The partial class declaration that connects markup to any code-behind defined for the partial class
> ルートのオブジェクト要素の終了。End of object element for the root. 要素に子要素が含まれているため、オブジェクトはまだ閉じられませんObject is not closed yet because the element contains child elements

XAML のオプションの使用方法と推奨されない使用方法Optional and Nonrecommended XAML Usages

以下のセクションで説明する XAML の使用方法は、XAML プロセッサによって技術的にはサポートされていますが、冗長さや他の審美的問題が発生し、XAML ソースが含まれるアプリケーションを開発するときに、ユーザーが XAML ファイルを読みにくくなります。The following sections describe XAML usages that are technically supported by XAML processors, but that produce verbosity or other aesthetic issues that interfere with XAML files remaining human-readable when you develop applications that contain XAML sources.

プロパティ要素のオプションの使用方法Optional Property Element Usages

プロパティ要素のオプションの使用方法には、XAML プロセッサによって暗黙的に考慮される要素コンテンツ プロパティの明示的な記述が含まれます。Optional property element usages include explicitly writing out element content properties that the XAML processor considers implicit. たとえば、Menu のコンテンツを宣言する場合、XAML プロセッサの暗黙の動作 (Menu のすべての子要素は MenuItem である必要があり、Items コレクションに配置される) を使用する代わりに、MenuItems コレクションを <Menu.Items> プロパティ要素タグとして明示的に宣言し、各 MenuItem<Menu.Items> 内に配置することができます。For example, when you declare the contents of a Menu, you could choose to explicitly declare the Items collection of the Menu as a <Menu.Items> property element tag, and place each MenuItem within <Menu.Items>, rather than using the implicit XAML processor behavior that all child elements of a Menu must be a MenuItem and are placed in the Items collection. このオプションの使用方法は、場合によっては、マークアップで表されるオブジェクト構造を視覚的に明確にするのに、役立つことがあります。Sometimes the optional usages can help to visually clarify the object structure as represented in the markup. または、場合によっては、プロパティ要素を明示的に使用すると、属性値内の入れ子になったマークアップ拡張のように、技術的には機能するものの、視覚的にはわかりにくいマークアップを回避できます。Or sometimes an explicit property element usage can avoid markup that is technically functional but visually confusing, such as nested markup extensions within an attribute value.

typeName.memberName の完全修飾属性Full typeName.memberName Qualified Attributes

属性の <型名>.<メンバー名> の形式は、実際には単なるルーティング イベントのケースより汎用的に機能します。The typeName.memberName form for an attribute actually works more universally than just the routed event case. ただし、マークアップのスタイルと読みやすさだけが理由の場合は、他の状況では、その形式は過剰であり、回避する必要があります。But in other situations that form is superfluous and you should avoid it, if only for reasons of markup style and readability. 次の例の Background 属性に対する 3 つの参照は、まったく同じになります。In the following example, each of the three references to the Background attribute are completely equivalent:

<Button Background="Blue">Background</Button>
<Button Button.Background="Blue">Button.Background</Button>
<Button Control.Background="Blue">Control.Background</Button>

Button.Background は、Button でのそのプロパティに対する修飾された参照が正常であり (Background は Control から継承されています)、Button はオブジェクト要素または基底クラスのクラスであるため、機能します。Button.Background works because the qualified lookup for that property on Button is successful (Background was inherited from Control) and Button is the class of the object element or a base class. Control.Background は、Control クラスで実際に Background が定義されていて、ControlButton 基底クラスであるため、機能します。Control.Background works because the Control class actually defines Background and Control is a Button base class.

ただし、その次の <型名>.<メンバー名> の形式の例は機能せず、そのため次のようにコメントされています。However, the following typeName.memberName form example does not work and is thus shown commented:

<!--<Button Label.Background="Blue">Does not work</Button> -->

LabelControl のもう 1 つの派生クラスであり、Label オブジェクト要素内で Label.Background を指定してあれば、この使用方法は動作したはずです。Label is another derived class of Control, and if you had specified Label.Background within a Label object element, this usage would have worked. しかし、LabelButton のクラスまたは基底クラスではないため、指定された XAML プロセッサの動作では、Label.Background は添付プロパティとして処理されます。However, because Label is not the class or base class of Button, the specified XAML processor behavior is to then process Label.Background as an attached property. Label.Background は使用可能な添付プロパティではないため、この使用方法は失敗します。Label.Background is not an available attached property, and this usage fails.

baseTypeName.memberName プロパティ要素baseTypeName.memberName Property Elements

属性構文に対して <型名>.<メンバー名> の形式が動作するのと同じように、プロパティ要素構文に対しては <基底型名>.<メンバー名> という構文が機能します。In an analogous way to how the typeName.memberName form works for attribute syntax, a baseTypeName.memberName syntax works for property element syntax. たとえば、次のような構文は機能します。For instance, the following syntax works:

<Button>Control.Background PE
  <Control.Background>
    <LinearGradientBrush StartPoint="0,0" EndPoint="1,1">
      <GradientStop Color="Yellow" Offset="0.0" />
      <GradientStop Color="LimeGreen" Offset="1.0" />
    </LinearGradientBrush>
    </Control.Background>
</Button>

ここでは、プロパティ要素は Button に含まれていますが、Control.Background として指定されています。Here, the property element was given as Control.Background even though the property element was contained in Button.

ただし、属性に対する <型名>.<メンバー名> の形式と同じように、<基底型名>.<メンバー名> はマークアップのスタイルとして不適切であるため、回避する必要があります。But just like typeName.memberName form for attributes, baseTypeName.memberName is poor style in markup, and you should avoid it.

関連項目See also