From 76317373cc9104ed2976c02f2e76a6b6d5a935fd Mon Sep 17 00:00:00 2001 From: Igor Velikorossov Date: Thu, 10 Sep 2020 15:34:07 +1000 Subject: [PATCH 1/4] Update defining-default-values-with-the-shouldserialize-and-reset-methods.md (#34) * Update defining-default-values-with-the-shouldserialize-and-reset-methods.md Make the methods private as those are invoked by convention. * Update dotnet-desktop-guide/framework/winforms/controls/defining-default-values-with-the-shouldserialize-and-reset-methods.md Co-authored-by: Andy De George <67293991+adegeo@users.noreply.github.com> Co-authored-by: Andy De George <67293991+adegeo@users.noreply.github.com> --- ...h-the-shouldserialize-and-reset-methods.md | 30 +++++++++++-------- 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/dotnet-desktop-guide/framework/winforms/controls/defining-default-values-with-the-shouldserialize-and-reset-methods.md b/dotnet-desktop-guide/framework/winforms/controls/defining-default-values-with-the-shouldserialize-and-reset-methods.md index 5d4fa8c426..6f2549de93 100644 --- a/dotnet-desktop-guide/framework/winforms/controls/defining-default-values-with-the-shouldserialize-and-reset-methods.md +++ b/dotnet-desktop-guide/framework/winforms/controls/defining-default-values-with-the-shouldserialize-and-reset-methods.md @@ -18,19 +18,22 @@ ms.assetid: 7b6c5e00-3771-46b4-9142-5a80d5864a5e - The designer generates more efficient code. - > [!NOTE] - > Either apply the or provide `Reset`*PropertyName* and `ShouldSerialize`*PropertyName* methods. Do not use both. +> [!NOTE] +> Either apply the or provide `Reset`*PropertyName* and `ShouldSerialize`*PropertyName* methods. Do not use both. + +When declaring a `ShouldSerialize` or `Reset` method, use the `private` access modifier. These methods are usually invoked by the designer and not by user code. The `Reset`*PropertyName* method sets a property to its default value, as shown in the following code fragment. ```vb -Public Sub ResetMyFont() +Private Sub ResetMyFont() MyFont = Nothing End Sub ``` ```csharp -public void ResetMyFont() { +private void ResetMyFont() +{ MyFont = null; } ``` @@ -43,15 +46,16 @@ public void ResetMyFont() { ```vb 'Returns true if the font has changed; otherwise, returns false. ' The designer writes code to the form only if true is returned. -Public Function ShouldSerializeMyFont() As Boolean - Return Not (thefont Is Nothing) +Private Function ShouldSerializeMyFont() As Boolean + Return thefont IsNot Nothing End Function ``` ```csharp // Returns true if the font has changed; otherwise, returns false. // The designer writes code to the form only if true is returned. -public bool ShouldSerializeMyFont() { +private bool ShouldSerializeMyFont() +{ return thefont != null; } ``` @@ -90,11 +94,11 @@ Public Class MyControl End Set End Property - Public Function ShouldSerializeMyFont() As Boolean - Return Not (thefont Is Nothing) + Private Function ShouldSerializeMyFont() As Boolean + Return thefont IsNot Nothing End Function - Public Sub ResetMyFont() + Private Sub ResetMyFont() MyFont = Nothing End Sub End Class @@ -124,11 +128,13 @@ public class MyControl : Control { } } - public bool ShouldSerializeMyFont() { + private bool ShouldSerializeMyFont() + { return thefont != null; } - public void ResetMyFont() { + private void ResetMyFont() + { MyFont = null; } } From 026b53dc58f3273584bdd0ec606211c96a059a58 Mon Sep 17 00:00:00 2001 From: Youssef Victor <31348972+Youssef1313@users.noreply.github.com> Date: Tue, 15 Sep 2020 22:17:04 +0200 Subject: [PATCH 2/4] Update xaml-syntax-in-detail.md (#43) --- .../wpf/advanced/xaml-syntax-in-detail.md | 553 +++++++++--------- 1 file changed, 283 insertions(+), 270 deletions(-) diff --git a/dotnet-desktop-guide/framework/wpf/advanced/xaml-syntax-in-detail.md b/dotnet-desktop-guide/framework/wpf/advanced/xaml-syntax-in-detail.md index 41597e5ec5..cfc978e48f 100644 --- a/dotnet-desktop-guide/framework/wpf/advanced/xaml-syntax-in-detail.md +++ b/dotnet-desktop-guide/framework/wpf/advanced/xaml-syntax-in-detail.md @@ -32,282 +32,295 @@ helpviewer_keywords: ms.assetid: 67cce290-ca26-4c41-a797-b68aabc45479 --- # XAML Syntax In Detail -This topic defines the terms that are used to describe the elements of XAML syntax. 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. This topic expands on the basic terminology introduced in the topic [XAML Overview (WPF)](/dotnet/desktop-wpf/fundamentals/xaml). - -## The XAML Language Specification - The XAML syntax terminology defined here is also defined or referenced within the XAML language specification. XAML is a language based on XML and follows or expands upon XML structural rules. 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. - - For more information about the XAML language specification, download [\[MS-XAML\]](https://download.microsoft.com/download/0/A/6/0A6F7755-9AF5-448B-907D-13985ACCF53E/[MS-XAML].pdf) from the Microsoft Download Center. - - -## XAML and CLR - XAML is a markup language. The common language runtime (CLR), as implied by its name, enables runtime execution. XAML is not by itself one of the common languages that is directly consumed by the CLR runtime. Instead, you can think of XAML as supporting its own type system. The particular XAML parsing system that is used by WPF is built on the CLR and the CLR type system. XAML types are mapped to CLR types to instantiate a run time representation when the XAML for WPF is parsed. 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. (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 - Properties and events as they appear as XAML members of a [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] type are often inherited from base types. For example, consider this example: ` -``` - - 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: - -```xaml - -``` - - A similarly illegal example is if the content property is a collection, and child elements are interspersed with property elements: - -```xaml - - - - - - - -``` - - -## 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. Similar to property element syntax for collection types, a XAML processor must identify types that are collection types. 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. The following is content syntax for a derived class. All derived classes establish the XAML content property to be , which requires a value of type . - - [!code-xaml[XAMLOvwSupport#SyntaxContent](~/samples/snippets/csharp/VS_Snippets_Wpf/XAMLOvwSupport/CSharp/page5.xaml#syntaxcontent)] - - Note that neither the property element for nor the element for the is required in the markup. This is a design feature of XAML so that recursively contained elements that define a [!INCLUDE[TLA2#tla_ui](../../../includes/tla2sharptla-ui-md.md)] are more intuitively represented as a tree of nested elements with immediate parent-child element relationships, without intervening property element tags or collection objects. In fact, cannot be specified explicitly in markup as an object element, by design. Because its only intended use is as an implicit collection, 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 - 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. This restriction against mixing property elements and content is enforced by the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] XAML processors. - - You can have a child object element as the first immediate markup within an object element. Then you can introduce property elements. 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 Namespaces - None of the preceding syntax examples specified a XAML namespace other than the default XAML namespace. In typical [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] applications, the default XAML namespace is specified to be the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] namespace. You can specify XAML namespaces other than the default XAML namespace and still use similar syntax. 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. For 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. - - For more information about XAML namespaces, see [XAML Namespaces and Namespace Mapping for WPF XAML](xaml-namespaces-and-namespace-mapping-for-wpf-xaml.md). - - -## Markup Extensions - 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. 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 (}). 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. - - The .NET XAML implementation uses the abstract class as the basis for all of the markup extensions supported by [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] as well as other frameworks or technologies. The markup extensions that [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] 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. 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. Many of the WPF markup extensions enable an attribute syntax for properties where an attribute syntax would not otherwise be possible. For example, a object is a relatively complex type that contains a nested series of objects and properties. Styles in WPF are typically defined as a resource in a , and then referenced through one of the two WPF markup extensions that request a resource. The markup extension defers the evaluation of the property value to a resource lookup and enables providing the value of the property, taking type , in attribute syntax as in the following example: - - `` - - Here, `StaticResource` identifies the class providing the markup extension implementation. The next string `MyStyle` is used as the input for the non-default constructor, where the parameter as taken from the extension string declares the requested . `MyStyle` is expected to be the [x:Key](/dotnet/desktop-wpf/xaml-services/xkey-directive) value of a defined as a resource. The [StaticResource Markup Extension](staticresource-markup-extension.md) usage requests that the resource be used to provide the property value through static resource lookup logic at load time. - - For more information about markup extensions, see [Markup Extensions and WPF XAML](markup-extensions-and-wpf-xaml.md). For a reference of markup extensions and other XAML programming features enabled in the general .NET XAML implementation, see [XAML Namespace (x:) Language Features](/dotnet/desktop-wpf/xaml-services/namespace-language-features). For WPF-specific markup extensions, see [WPF XAML Extensions](wpf-xaml-extensions.md). - - -## Attached Properties - Attached properties are a programming concept introduced in XAML whereby properties can be owned and defined by a particular type, but set as attributes or property elements on any element. The primary scenario that attached properties are intended for is to enable child elements in a markup structure to report information to a parent element without requiring an extensively shared object model across all elements. Conversely, attached properties can be used by parent elements to report information to child elements. For more information on the purpose of attached properties and how to create your own attached properties, see [Attached Properties Overview](attached-properties-overview.md). - - Attached properties use a syntax that superficially resembles property element syntax, in that you also specify a *typeName*.*propertyName* combination. There are two important differences: - -- You can use the *typeName*.*propertyName* combination even when setting an attached property through attribute syntax. Attached properties are the only case where qualifying the property name is a requirement in an attribute syntax. - -- You can also use property element syntax for attached properties. However, for typical property element syntax, the *typeName* you specify is the object element that contains the property element. If you are referring to an attached property, then the *typeName* is the class that defines the attached property, not the containing object element. - - -## Attached Events - 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. 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. 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. - - -## Anatomy of a XAML Root Element - The following table shows a typical XAML root element broken down, showing the specific attributes of a root element: - -||| -|-|-| -|``|End of object element for the root. Object is not closed yet because the element contains child elements| - - -## Optional and Nonrecommended XAML Usages - 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 - Optional property element usages include explicitly writing out element content properties that the XAML processor considers implicit. For example, when you declare the contents of a , you could choose to explicitly declare the collection of the as a `` property element tag, and place each within ``, rather than using the implicit XAML processor behavior that all child elements of a must be a and are placed in the 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. - -### Full typeName.memberName Qualified Attributes - The *typeName*.*memberName* form for an attribute actually works more universally than just the routed event case. But in other situations that form is superfluous and you should avoid it, if only for reasons of markup style and readability. In the following example, each of the three references to the attribute are completely equivalent: - - [!code-xaml[XAMLOvwSupport#TypeNameProp](~/samples/snippets/csharp/VS_Snippets_Wpf/XAMLOvwSupport/CSharp/page8.xaml#typenameprop)] - - `Button.Background` works because the qualified lookup for that property on is successful ( was inherited from Control) and is the class of the object element or a base class. `Control.Background` works because the class actually defines and is a base class. - - However, the following *typeName*.*memberName* form example does not work and is thus shown commented: - - [!code-xaml[XAMLOvwSupport#TypeNameBadProp](~/samples/snippets/csharp/VS_Snippets_Wpf/XAMLOvwSupport/CSharp/page8.xaml#typenamebadprop)] - - is another derived class of , and if you had specified `Label.Background` within a object element, this usage would have worked. However, because is not the class or base class of , the specified XAML processor behavior is to then process `Label.Background` as an attached property. `Label.Background` is not an available attached property, and this usage fails. - -### baseTypeName.memberName Property Elements - In an analogous way to how the *typeName*.*memberName* form works for attribute syntax, a *baseTypeName*.*memberName* syntax works for property element syntax. For instance, the following syntax works: - - [!code-xaml[XAMLOvwSupport#GoofyPE](~/samples/snippets/csharp/VS_Snippets_Wpf/XAMLOvwSupport/CSharp/page8.xaml#goofype)] - - Here, the property element was given as `Control.Background` even though the property element was contained in `Button`. - - But just like *typeName*.*memberName* form for attributes, *baseTypeName*.*memberName* is poor style in markup, and you should avoid it. - + Blue + blue button +``` + +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: + +```xaml + +``` + +A similarly illegal example is if the content property is a collection, and child elements are interspersed with property elements: + +```xaml + + + + + + + +``` + +## 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. Similar to property element syntax for collection types, a XAML processor must identify types that are collection types. 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. The following is content syntax for a derived class. All derived classes establish the XAML content property to be , which requires a value of type . + +[!code-xaml[XAMLOvwSupport#SyntaxContent](~/samples/snippets/csharp/VS_Snippets_Wpf/XAMLOvwSupport/CSharp/page5.xaml#syntaxcontent)] + +Note that neither the property element for nor the element for the is required in the markup. This is a design feature of XAML so that recursively contained elements that define a [!INCLUDE[TLA2#tla_ui](../../../includes/tla2sharptla-ui-md.md)] are more intuitively represented as a tree of nested elements with immediate parent-child element relationships, without intervening property element tags or collection objects. In fact, cannot be specified explicitly in markup as an object element, by design. Because its only intended use is as an implicit collection, 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 + +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. This restriction against mixing property elements and content is enforced by the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] XAML processors. + +You can have a child object element as the first immediate markup within an object element. Then you can introduce property elements. 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 Namespaces + +None of the preceding syntax examples specified a XAML namespace other than the default XAML namespace. In typical [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] applications, the default XAML namespace is specified to be the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] namespace. You can specify XAML namespaces other than the default XAML namespace and still use similar syntax. 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. For 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. + +For more information about XAML namespaces, see [XAML Namespaces and Namespace Mapping for WPF XAML](xaml-namespaces-and-namespace-mapping-for-wpf-xaml.md). + +## Markup Extensions + +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. 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 (}). 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. + +The .NET XAML implementation uses the abstract class as the basis for all of the markup extensions supported by [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] as well as other frameworks or technologies. The markup extensions that [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] 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. 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. Many of the WPF markup extensions enable an attribute syntax for properties where an attribute syntax would not otherwise be possible. For example, a object is a relatively complex type that contains a nested series of objects and properties. Styles in WPF are typically defined as a resource in a , and then referenced through one of the two WPF markup extensions that request a resource. The markup extension defers the evaluation of the property value to a resource lookup and enables providing the value of the property, taking type , in attribute syntax as in the following example: + +```xaml + +``` + +Here, `StaticResource` identifies the class providing the markup extension implementation. The next string `MyStyle` is used as the input for the non-default constructor, where the parameter as taken from the extension string declares the requested . `MyStyle` is expected to be the [x:Key](/dotnet/desktop-wpf/xaml-services/xkey-directive) value of a defined as a resource. The [StaticResource Markup Extension](staticresource-markup-extension.md) usage requests that the resource be used to provide the property value through static resource lookup logic at load time. + +For more information about markup extensions, see [Markup Extensions and WPF XAML](markup-extensions-and-wpf-xaml.md). For a reference of markup extensions and other XAML programming features enabled in the general .NET XAML implementation, see [XAML Namespace (x:) Language Features](/dotnet/desktop-wpf/xaml-services/namespace-language-features). For WPF-specific markup extensions, see [WPF XAML Extensions](wpf-xaml-extensions.md). + +## Attached Properties + +Attached properties are a programming concept introduced in XAML whereby properties can be owned and defined by a particular type, but set as attributes or property elements on any element. The primary scenario that attached properties are intended for is to enable child elements in a markup structure to report information to a parent element without requiring an extensively shared object model across all elements. Conversely, attached properties can be used by parent elements to report information to child elements. For more information on the purpose of attached properties and how to create your own attached properties, see [Attached Properties Overview](attached-properties-overview.md). + +Attached properties use a syntax that superficially resembles property element syntax, in that you also specify a *typeName*.*propertyName* combination. There are two important differences: + +- You can use the *typeName*.*propertyName* combination even when setting an attached property through attribute syntax. Attached properties are the only case where qualifying the property name is a requirement in an attribute syntax. + +- You can also use property element syntax for attached properties. However, for typical property element syntax, the *typeName* you specify is the object element that contains the property element. If you are referring to an attached property, then the *typeName* is the class that defines the attached property, not the containing object element. + +## Attached Events + +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. In the WPF 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. 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. + +## Anatomy of a XAML Root Element + +The following table shows a typical XAML root element broken down, showing the specific attributes of a root element: + +||| +|-|-| +|``|End of object element for the root. Object is not closed yet because the element contains child elements| + +## Optional and Nonrecommended XAML Usages + +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 + +Optional property element usages include explicitly writing out element content properties that the XAML processor considers implicit. For example, when you declare the contents of a , you could choose to explicitly declare the collection of the as a `` property element tag, and place each within ``, rather than using the implicit XAML processor behavior that all child elements of a must be a and are placed in the 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. + +### Full typeName.memberName Qualified Attributes + +The *typeName*.*memberName* form for an attribute actually works more universally than just the routed event case. But in other situations that form is superfluous and you should avoid it, if only for reasons of markup style and readability. In the following example, each of the three references to the attribute are completely equivalent: + +[!code-xaml[XAMLOvwSupport#TypeNameProp](~/samples/snippets/csharp/VS_Snippets_Wpf/XAMLOvwSupport/CSharp/page8.xaml#typenameprop)] + +`Button.Background` works because the qualified lookup for that property on is successful ( was inherited from Control) and is the class of the object element or a base class. `Control.Background` works because the class actually defines and is a base class. + +However, the following *typeName*.*memberName* form example does not work and is thus shown commented: + +[!code-xaml[XAMLOvwSupport#TypeNameBadProp](~/samples/snippets/csharp/VS_Snippets_Wpf/XAMLOvwSupport/CSharp/page8.xaml#typenamebadprop)] + + is another derived class of , and if you had specified `Label.Background` within a object element, this usage would have worked. However, because is not the class or base class of , the specified XAML processor behavior is to then process `Label.Background` as an attached property. `Label.Background` is not an available attached property, and this usage fails. + +### baseTypeName.memberName Property Elements + +In an analogous way to how the *typeName*.*memberName* form works for attribute syntax, a *baseTypeName*.*memberName* syntax works for property element syntax. For instance, the following syntax works: + +[!code-xaml[XAMLOvwSupport#GoofyPE](~/samples/snippets/csharp/VS_Snippets_Wpf/XAMLOvwSupport/CSharp/page8.xaml#goofype)] + +Here, the property element was given as `Control.Background` even though the property element was contained in `Button`. + +But just like *typeName*.*memberName* form for attributes, *baseTypeName*.*memberName* is poor style in markup, and you should avoid it. + ## See also - [XAML Overview (WPF)](/dotnet/desktop-wpf/fundamentals/xaml) From b98f4b893275c61b28303cfd41bb966cede5c054 Mon Sep 17 00:00:00 2001 From: Milos Zivadinovic <41507350+ignispotentia@users.noreply.github.com> Date: Mon, 12 Oct 2020 22:40:08 +0200 Subject: [PATCH 3/4] Fix missing letter in first link of article (#68) --- .../framework/wpf/advanced/dependency-properties-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dotnet-desktop-guide/framework/wpf/advanced/dependency-properties-overview.md b/dotnet-desktop-guide/framework/wpf/advanced/dependency-properties-overview.md index eb5228a617..6bc62b0c86 100644 --- a/dotnet-desktop-guide/framework/wpf/advanced/dependency-properties-overview.md +++ b/dotnet-desktop-guide/framework/wpf/advanced/dependency-properties-overview.md @@ -17,7 +17,7 @@ ms.assetid: d119d00c-3afb-48d6-87a0-c4da4f83dee5 --- # Dependency properties overview -Windows Presentation Foundation (WPF) provides a set of services that can be used to extend the functionality of a type's [property](/dotnet/standard/base-types/common-type-syste#properties). Collectively, these services are typically referred to as the WPF property system. A property that is backed by the WPF property system is known as a dependency property. This overview describes the WPF property system and the capabilities of a dependency property. This includes how to use existing dependency properties in XAML and in code. This overview also introduces specialized aspects of dependency properties, such as dependency property metadata, and how to create your own dependency property in a custom class. +Windows Presentation Foundation (WPF) provides a set of services that can be used to extend the functionality of a type's [property](/dotnet/standard/base-types/common-type-system#properties). Collectively, these services are typically referred to as the WPF property system. A property that is backed by the WPF property system is known as a dependency property. This overview describes the WPF property system and the capabilities of a dependency property. This includes how to use existing dependency properties in XAML and in code. This overview also introduces specialized aspects of dependency properties, such as dependency property metadata, and how to create your own dependency property in a custom class. ## Prerequisites This topic assumes that you have some basic knowledge of the .NET type system and object-oriented programming. In order to follow the examples in this topic, you should also understand XAML and know how to write WPF applications. For more information, see [Walkthrough: My first WPF desktop application](../getting-started/walkthrough-my-first-wpf-desktop-application.md). From 5c89943e825d947f5bc4e0d0187d06c2c9eb3583 Mon Sep 17 00:00:00 2001 From: "Andy (Steve) De George" <67293991+adegeo@users.noreply.github.com> Date: Tue, 1 Feb 2022 15:16:51 -0800 Subject: [PATCH 4/4] Update xaml-syntax-in-detail.md --- .../wpf/advanced/xaml-syntax-in-detail.md | 109 +++++------------- 1 file changed, 32 insertions(+), 77 deletions(-) diff --git a/dotnet-desktop-guide/framework/wpf/advanced/xaml-syntax-in-detail.md b/dotnet-desktop-guide/framework/wpf/advanced/xaml-syntax-in-detail.md index 7bc0475392..3d30cea348 100644 --- a/dotnet-desktop-guide/framework/wpf/advanced/xaml-syntax-in-detail.md +++ b/dotnet-desktop-guide/framework/wpf/advanced/xaml-syntax-in-detail.md @@ -36,39 +36,9 @@ ms.assetid: 67cce290-ca26-4c41-a797-b68aabc45479 This topic defines the terms that are used to describe the elements of XAML syntax. 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. This topic expands on the basic terminology introduced in the topic [XAML in WPF](xaml-in-wpf.md). -This topic defines the terms that are used to describe the elements of XAML syntax. 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. This topic expands on the basic terminology introduced in the topic [XAML Overview (WPF)](/dotnet/desktop-wpf/fundamentals/xaml). - -## The XAML Language Specification - -The XAML syntax terminology defined here is also defined or referenced within the XAML language specification. XAML is a language based on XML and follows or expands upon XML structural rules. 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. - -For more information about the XAML language specification, download [\[MS-XAML\]](https://download.microsoft.com/download/0/A/6/0A6F7755-9AF5-448B-907D-13985ACCF53E/[MS-XAML].pdf) from the Microsoft Download Center. - -## XAML and CLR - -XAML is a markup language. The common language runtime (CLR), as implied by its name, enables runtime execution. XAML is not by itself one of the common languages that is directly consumed by the CLR runtime. Instead, you can think of XAML as supporting its own type system. The particular XAML parsing system that is used by WPF is built on the CLR and the CLR type system. XAML types are mapped to CLR types to instantiate a run time representation when the XAML for WPF is parsed. 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. (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 - -Properties and events as they appear as XAML members of a [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] type are often inherited from base types. For example, consider this example: `