Stone_Red/docs-desktop
1
0
Fork 0
mirror of https://github.com/Stone-Red-Code/docs-desktop.git synced 2026-09-07 07:56:07 +02:00
Code Issues Packages Projects Releases Wiki Activity

Replace various WPF include files with content (#1335)

Browse Source 
* net-current-v30plus-md.md

* net-current-v40plus-md.md

* tla2sharptla-ui-md.md

* tla2sharptla-uiautomation-md.md

* tla2sharptla-winclient-md.md

* tla2sharptla-xaml-md.md

* tlasharptla-ui-md.md

* tlasharptla-uiautomation-md.md

* tlasharptla-winclient-md.md

* tlasharptla-xaml-md.md

* fix warnings
This commit is contained in:
Andy (Steve) De George
2022-03-16 12:14:11 -04:00
committed by GitHub
parent dd0052ecec
commit be103da07e
353 changed files with 1339 additions and 1349 deletions
Download Patch File Download Diff File Expand all files Collapse all files
dotnet-desktop-guide/framework/wpf/advanced/framework-property-metadata.md
+6 -6
View File
@@ -7,11 +7,11 @@ helpviewer_keywords:
ms.assetid: 9962f380-b885-4b61-a62e-457397083fea
---
# Framework Property Metadata
Framework property metadata options are reported for the properties of object elements considered to be at the WPF framework level in the [!INCLUDE[TLA#tla_winclient](../../../includes/tlasharptla-winclient-md.md)] architecture. In general the WPF framework-level designation entails that features such as rendering, data binding, and property system refinements are handled by the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] presentation APIs and executables. Framework property metadata is queried by these systems to determine feature-specific characteristics of particular element properties.
Framework property metadata options are reported for the properties of object elements considered to be at the WPF framework level in the WPF presentation APIs and executables. Framework property metadata is queried by these systems to determine feature-specific characteristics of particular element properties.
<a name="prerequisites"></a>
## Prerequisites
This topic assumes that you understand dependency properties from the perspective of a consumer of existing dependency properties on [!INCLUDE[TLA#tla_winclient](../../../includes/tlasharptla-winclient-md.md)] classes, and have read the [Dependency Properties Overview](dependency-properties-overview.md). You should also have read [Dependency Property Metadata](dependency-property-metadata.md).
This topic assumes that you understand dependency properties from the perspective of a consumer of existing dependency properties on Windows Presentation Foundation (WPF) classes, and have read the [Dependency Properties Overview](dependency-properties-overview.md). You should also have read [Dependency Property Metadata](dependency-property-metadata.md).
<a name="What_Is_Communicated_by_Framework_Property"></a>
## What Is Communicated by Framework Property Metadata
@@ -24,11 +24,11 @@ Framework property metadata options are reported for the properties of object el
- <xref:System.Windows.FrameworkPropertyMetadata.Inherits%2A>. By default, dependency properties do not inherit values. <xref:System.Windows.FrameworkPropertyMetadata.OverridesInheritanceBehavior%2A> allows the pathway of inheritance to also travel into a visual tree, which is necessary for some control compositing scenarios.
> [!NOTE]
> The term "inherits" in the context of property values means something specific for dependency properties; it means that child elements can inherit the actual dependency property value from parent elements because of a WPF framework-level capability of the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] property system. It has nothing to do directly with managed code type and members inheritance through derived types. For details, see [Property Value Inheritance](property-value-inheritance.md).
> The term "inherits" in the context of property values means something specific for dependency properties; it means that child elements can inherit the actual dependency property value from parent elements because of a WPF framework-level capability of the WPF property system. It has nothing to do directly with managed code type and members inheritance through derived types. For details, see [Property Value Inheritance](property-value-inheritance.md).
- Reporting data binding characteristics (<xref:System.Windows.FrameworkPropertyMetadata.IsNotDataBindable%2A>, <xref:System.Windows.FrameworkPropertyMetadata.BindsTwoWayByDefault%2A>). By default, dependency properties in the framework support data binding, with a one-way binding behavior. You might disable data binding if there were no scenario for it whatsoever (because they are intended to be flexible and extensible, there aren't many examples of such properties in the default [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] APIs). You might set binding to have a two-way default for properties that tie together a control's behaviors amongst its component pieces (<xref:System.Windows.Controls.MenuItem.IsSubmenuOpen%2A> is an example) or where two-way binding is the common and expected scenario for users (<xref:System.Windows.Controls.TextBox.Text%2A> is an example). Changing the data binding–related metadata only influences the default; on a per-binding basis that default can always be changed. For details on the binding modes and binding in general, see [Data Binding Overview](../data/data-binding-overview.md).
- Reporting data binding characteristics (<xref:System.Windows.FrameworkPropertyMetadata.IsNotDataBindable%2A>, <xref:System.Windows.FrameworkPropertyMetadata.BindsTwoWayByDefault%2A>). By default, dependency properties in the framework support data binding, with a one-way binding behavior. You might disable data binding if there were no scenario for it whatsoever (because they are intended to be flexible and extensible, there aren't many examples of such properties in the default WPF APIs). You might set binding to have a two-way default for properties that tie together a control's behaviors amongst its component pieces (<xref:System.Windows.Controls.MenuItem.IsSubmenuOpen%2A> is an example) or where two-way binding is the common and expected scenario for users (<xref:System.Windows.Controls.TextBox.Text%2A> is an example). Changing the data binding–related metadata only influences the default; on a per-binding basis that default can always be changed. For details on the binding modes and binding in general, see [Data Binding Overview](../data/data-binding-overview.md).
- Reporting whether properties should be journaled by applications or services that support journaling (<xref:System.Windows.FrameworkPropertyMetadata.Journal%2A>). For general elements, journaling is not enabled by default, but it is selectively enabled for certain user input controls. This property is intended to be read by journaling services including the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] implementation of journaling, and is typically set on user controls such as user selections within lists that should be persisted across navigation steps. For information about the journal, see [Navigation Overview](../app-development/navigation-overview.md).
- Reporting whether properties should be journaled by applications or services that support journaling (<xref:System.Windows.FrameworkPropertyMetadata.Journal%2A>). For general elements, journaling is not enabled by default, but it is selectively enabled for certain user input controls. This property is intended to be read by journaling services including the WPF implementation of journaling, and is typically set on user controls such as user selections within lists that should be persisted across navigation steps. For information about the journal, see [Navigation Overview](../app-development/navigation-overview.md).
<a name="Reading_FrameworkPropertyMetadata"></a>
## Reading FrameworkPropertyMetadata
@@ -36,7 +36,7 @@ Framework property metadata options are reported for the properties of object el
<a name="Specifying_Metadata"></a>
## Specifying Metadata
When you create a new metadata instance for purposes of applying metadata to a new dependency property registration, you have the choice of which metadata class to use: the base <xref:System.Windows.PropertyMetadata> or some derived class such as <xref:System.Windows.FrameworkPropertyMetadata>. In general, you should use <xref:System.Windows.FrameworkPropertyMetadata>, particularly if your property has any interaction with property system and [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] functions such as layout and data binding. Another option for more sophisticated scenarios is to derive from <xref:System.Windows.FrameworkPropertyMetadata> to create your own metadata reporting class with extra information carried in its members. Or you might use <xref:System.Windows.PropertyMetadata> or <xref:System.Windows.UIPropertyMetadata> to communicate the degree of support for features of your implementation.
When you create a new metadata instance for purposes of applying metadata to a new dependency property registration, you have the choice of which metadata class to use: the base <xref:System.Windows.PropertyMetadata> or some derived class such as <xref:System.Windows.FrameworkPropertyMetadata>. In general, you should use <xref:System.Windows.FrameworkPropertyMetadata>, particularly if your property has any interaction with property system and WPF functions such as layout and data binding. Another option for more sophisticated scenarios is to derive from <xref:System.Windows.FrameworkPropertyMetadata> to create your own metadata reporting class with extra information carried in its members. Or you might use <xref:System.Windows.PropertyMetadata> or <xref:System.Windows.UIPropertyMetadata> to communicate the degree of support for features of your implementation.
For existing properties (<xref:System.Windows.DependencyProperty.AddOwner%2A> or <xref:System.Windows.DependencyProperty.OverrideMetadata%2A> call), you should always override with the metadata type used by the original registration.