XAML 構文の詳細XAML Syntax In Detail

このトピックでは、XAML 構文の要素の説明に使用される用語を定義します。This topic defines the terms that are used to describe the elements of XAML syntax. これらの用語は、具体的には、XAML または System.Xaml レベルでの XAML 言語のサポートを有効になっている XAML の基本的な概念を使用する他のフレームワークも、このドキュメントは、WPF のドキュメントの両方の残りの部分でよく使用されます。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 言語仕様の詳細については、ダウンロード [MS XAML] Microsoft ダウンロード センターから。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)common language runtime (CLR)、として、名前により、ランタイムの実行によって暗黙的に指定します。The 共通言語ランタイム (CLR)common language runtime (CLR), as implied by its name, enables runtime execution. XAML は単独で、CLR ランタイムによって直接使用される一般的な言語のいずれか。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. このため、このドキュメントの構文のディスカッションの残りの部分は、XAML 言語仕様で同等の構文の説明がない場合でも、CLR 型システムへの参照を含まれます。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

プロパティおよびの XAML メンバーとして表示されますが、イベント、WPFWPF型が基本型から継承された多くの場合。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.

クラスの継承動作WPFWPFXAML 要素が 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. これは、1 つの理由の XAML 要素およびその許容属性のセットが正確かつ完全には、スキーマ型を使用して表さ難しくは通常の使用をXMLXMLプログラミングでは、DTD または XSD 形式などです。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. 別の理由は、その機能を拡張し、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 つまたは複数のスペースを含む ="value"ペア。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. 対応するオブジェクト要素のタグを終了する必要がありますも適切な入れ子でが存在し、他の開始と終了タグのペアとバランスを取る。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 では、オブジェクトの要素を型、プロパティまたはイベント、および CLR 名前空間とアセンブリに XAML 名前空間への属性にマッピングする規則のセットがあります。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. コンテンツ コントロールおよびその他のクラスのページで、「解説」の一部として特定要素モデルが記載されているWPFWPFXAML 要素として使用できるクラス。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 default 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 パーサーで本質的に処理され、列挙型の名前付き定数のいずれかの文字列名を指定して列挙体のメンバーを指定する必要があります。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.)

使用して既定の名前空間を介してアクセス可能な任意のオブジェクトからすべてのイベントを付けることができます、 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. この構文には、添付イベント構文が似ていますが、ここで、イベントが true の添付イベントではありません。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.dependencyPropertyNameします。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.

プロパティ名の別の使用方法では、属性値がプロパティ間のリレーションシップについて説明します。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. 開始要素を使用してプロパティを指定、要素タグ内の属性として指定されているプロパティの代わりにタグを付ける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. プロパティに割り当てられる値は、プロパティ要素内に含まれています。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. 最後に、同じを指定する同等の終了タグelementTypeName.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). 別のシナリオはようにX:uid ディレクティブプロパティ要素に適用できるし、したがってを BAML の出力を WPF でローカライズする必要がある値、またはその他の技法によって内の値をマークします。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.

Property 要素は、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. たとえば、TriggersプロパティのStyleは特殊なコレクション型を受け取ります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(または派生クラス) は厳密に型指定されたと暗黙的な項目の種類として期待される型です。 TriggerCollectionInstead, 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 つのインスタンスか、列内の項目のいずれか親のコレクション型プロパティ値でもある 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、および XAML の負荷の Api の動作の強化は頻繁にLoadします。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 default constructor, and TriggerCollection does not have a default 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. 明示的な/verbose 手法がマークアップをわかりやすくするため、またはマークアップのスタイルの問題を親と子として直感的に関連する要素を直接はネストされるように、マークアップを効率化するコンテンツ プロパティの目的は、通常は。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. これは、文字列、または 1 つまたは複数のオブジェクトとして、XAML コンテンツ プロパティの値が指定されているかどうか。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

そのまま使用するために複数のコンテンツとして 1 つのオブジェクト要素コンテンツのプロパティの型する必要があります具体的にはコレクション型であります。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 コンテンツ プロパティがプロパティ el として指定する必要はありません。ement します。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. そのため、マークアップで明らかなコンテンツ モデル コンテンツとして割り当てられている 1 つ以上の子要素を指定できます。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 default 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に指定する 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 名前空間内でアクセス可能でないクラス名にする必要がありますの前に、XAML 名前空間のプレフィックスに対応する CLR 名前空間にマップします。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 のマッピングの Namespaceします。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. その後は単一の空白が表示されますし、後続の各文字が入力として使用拡張機能の実装で中かっこが検出されるまで。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、リソースを要求する WPF のマークアップの 2 つの拡張機能のいずれかで参照します。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 必要です、 X:keyの値をStyleをリソースとして定義されます。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 Namespace (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プロパティ要素が含まれるオブジェクトの要素を指定します。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 で導入されたもう 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. 許可する添付イベントの属性の構文を展開する添付イベントは、使用、 typeName.eventNameの使用状況、 typeNameを提供するクラスは、AddRemove、添付イベント インフラストラクチャのためのイベント ハンドラーのアクセサーと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を明示的に宣言することもできます、Itemsのコレクション、Menuとして、<Menu.Items>プロパティ要素のタグおよび配置MenuItem<Menu.Items>ではなく、暗黙的な XAML プロセッサの動作を使用するよりものすべての子要素をMenu必要があります、MenuItemに配置し、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

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. 参照、3 つ次の例では、Background属性は完全に同等です。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 form の例は行われず、コメントがあるため表示されます。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.Background内、Labelオブジェクト要素の場合は、この使用法がならばします。Label is another derived class of Control, and if you had specified Label.Background within a Label object element, this usage would have worked. ただし、ためLabelクラスまたは基底クラスのないButtonを処理し、指定した 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します。Here, the property element was given as Control.Background even though the property element was contained in Button.

同じように、 typeName.memberName属性について、フォームbaseTypeName.memberNameマークアップでは、不適切なスタイルは、これを避ける必要があります。But just like typeName.memberName form for attributes, baseTypeName.memberName is poor style in markup, and you should avoid it.

関連項目See also