XAML 構文の詳細XAML Syntax In Detail

このトピックでは、XAML 構文の要素について説明するために使用される用語を定義します。This topic defines the terms that are used to describe the elements of XAML syntax. これらの用語は、このドキュメントの残りの部分で頻繁に使用されます。 WPF ドキュメントについては、特に、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" .../>. クラス定義、リフレクション結果、またはドキュメントをButton参照する場合、プロパティは、クラスですぐに宣言されたプロパティではありません。BackgroundThe 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.

XAML 要素のWPFWPFクラス継承動作は、スキーマが適用される 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. これは、XAML 要素のセットとその使用可能な属性が、DTD や XSD 形式などのXMLXMLプログラミングで通常使用されるスキーマ型を正確かつ完全に表現することが困難な理由の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 XMLXML 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個以上の属性を object 要素で宣言することもできます。また、各属性名 = "value" ペアを区切る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. 最後に、次のいずれかが true である必要があります。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. Object 要素の終了タグは、他の開始タグと終了タグのペアと適切に入れ子にして、バランスを取る必要もあります。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 Framework では、XAML オブジェクト要素は参照Microsoft .NETMicrosoft .NETアセンブリで定義されている型にマップされ、属性はそれらの型のメンバーにマップされます。For WPF and the .NET Framework, XAML object elements map to Microsoft .NETMicrosoft .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通常、などMenuBase Menuの派生クラスの子としてのみ配置する必要があります。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. 列挙体は、format列挙体では指定しません。。コードの場合と同じです。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. ただし、このような列挙StyleSimulations体の1つはです。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.)

また、 typeNameを使用して、既定の名前空間を介してアクセスできる任意のオブジェクトから、任意のイベントの名前を指定することもできます。イベント部分修飾名;この構文では、ルーティングイベントのハンドラーのアタッチがサポートされています。このハンドラーは、子要素からのイベントルーティングを処理することを意図していますが、親要素はそのメンバーテーブルにそのイベントを持っていません。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. このプロパティ名には、 ownerTypeの形式で指定されたプロパティなどの修飾子を含めることもできます。DependencypropertynameThat 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 要素の構文Property Element Syntax

Property 要素の構文は、要素の基本的な 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. この機能は、property 要素の構文によって有効になります。This capability is enabled by the property element syntax. 要素タグ内の属性として指定されているプロパティではなく、 Elementtypenameの開始要素タグを使用してプロパティが指定されています。propertyNameフォームでは、プロパティの値が内で指定され、プロパティ要素が閉じられます。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. プロパティに割り当てられる値は、property 要素内に格納されます。The value to be assigned to the property is contained within the property element. 通常、値は1つ以上のオブジェクト要素として指定されます。これは、オブジェクトを値として指定することが、property 要素の構文が対処するシナリオであるためです。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. 最後に、同じElementtypenameを指定する、同等の終了タグを指定します。propertyNameを適切に入れ子にし、他の要素タグとのバランスを取るには、propertyName の組み合わせを指定する必要があります。Finally, an equivalent closing tag specifying the same elementTypeName.propertyName combination must be provided, in proper nesting and balance with other element tags.

たとえば、 ContextMenu Buttonのプロパティのプロパティ要素構文を次に示します。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 ディレクティブを property 要素に適用し、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. 代わりに、コレクション内の項目になる要素は、property 要素の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. たとえば、のプロパティTriggersは、 Styleを実装IListする特殊なTriggerCollectionコレクション型を受け取ります。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. 代わりに、 Style.Triggersプロパティ要素内の要素Triggerとして1つ以上の項目を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>クラスは、直接実装するかDictionary<TKey,TValue> 、基底クラスIDictionaryとしてIList直接実装するため、基底クラスとして使用できます。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 参照ページでは、コレクションの object 要素を意図的に省略したこの構文は、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). つまり、マークアップページの親要素と子要素の関係は、実際にはルートの単一のオブジェクトであり、ルートの下にあるすべてのオブジェクト要素は、親のプロパティ値を提供する単一のインスタンスか、または col 内のいずれかの項目です。親のコレクション型のプロパティ値でもある lection います。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. たとえば、前に示しTriggerCollection Triggersた例でを明示的に宣言しようとすると失敗します。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. Content プロパティの明示的なプロパティ要素を指定することは許可されていますが、この使用方法は一般に .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 言語定義では "content" として割り当てられません。これらは、以前に 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>  

これは基本的に、コンテンツプロパティの property 要素構文を使用してこの構文が明示的に作成されている場合、content プロパティは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 Childrenの派生クラスは、型UIElementCollectionの値を必要とする XAML コンテンツプロパティをに設定します。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つまたは複数の property 要素、次にコンテンツ、さらにプロパティ要素を指定することもできます。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なアプリケーションでは、既定の XAML 名前空間が名前WPFWPF空間として指定されます。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 prefix。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 名前空間の詳細については、「 WPF xaml の 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 の実装ではMarkupExtension 、でWPFWPFサポートされているすべてのマークアップ拡張機能の基礎として抽象クラスを使用し、他のフレームワークやテクノロジも使用します。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. たとえば、単純な WPF データバインディングは、特定のプロパティが{Binding}通常受け取る値の代わりにマークアップ拡張機能を指定することによって実現されます。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は、 Styleリソースとして定義されているのx: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.

添付プロパティでは、 typeNameを指定することによって、プロパティ要素の構文に似た構文を使用します、一見、。propertyNameの組み合わせ。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:

  • TypeNameを使用できます。属性構文を介して添付プロパティを設定する場合でも、 propertyNameの組み合わせ。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. ただし、プロパティ要素の一般的な構文では、指定するtypeNameは property 要素を含む object 要素です。However, for typical property element syntax, the typeName you specify is the object element that contains the property element. 添付プロパティを参照している場合、 typeNameは添付プロパティを定義するクラスであり、それを含んでいるオブジェクト要素ではありません。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 で導入された別のプログラミング概念であり、特定の型でイベントを定義できますが、どのオブジェクト要素にもハンドラーをアタッチできます。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. 添付イベントと同様に、 typeNameを許可するために、添付イベントの属性構文が拡張されています。eventname usage。ここで、 typeNameは添付イベントAddインフラストラクチャRemoveのイベントハンドラーアクセサーを提供するクラスであり、 eventNameはイベント名です。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の内容を宣言するときに、のMenuItem Items Menu <Menu.Items>コレクションをプロパティ要素タグとして明示的に宣言し、それぞれを内<Menu.Items>に配置することもできます。暗黙の XAML プロセッサの動作は、のすべてのMenu子要素がである必要がありMenuItemItemsコレクションに配置されることを示します。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

TypeNameです。属性のmemberNameフォームは、ルーティングイベントのケースだけでなく、実際にはより汎用的に機能します。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コントロールから継承された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実際にを定義BackgroundControl 、はButton基底クラスであるため、機能します。Control.Background works because the Control class actually defines Background and Control is a Button base class.

ただし、次のtypeNameは次のようになります。memberNameフォームの例は機能しません。そのため、次のコメントが表示されます。However, the following typeName.memberName form example does not work and is thus shown commented:

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

Labelはの別のControl派生クラスであり、 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

TypeNameの方法に似ています。memberNameフォームは、 basetypenameという属性構文に対して機能します。memberName構文は、プロパティ要素構文で使用できます。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>

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

ただし、 typeNameと同様です。属性のmemberNameフォーム、 basetypenamememberNameはマークアップの形式が不適切なため、回避する必要があります。But just like typeName.memberName form for attributes, baseTypeName.memberName is poor style in markup, and you should avoid it.

関連項目See also