Replace various WPF include files with content (#1335)

* 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
@@ -12,16 +12,16 @@ helpviewer_keywords:
ms.assetid: 52bbf4f2-15fc-40d4-837b-bb4c21ead7d4
---
# WPF XAML Namescopes
XAML namescopes are a concept that identifies objects that are defined in XAML. The names in a XAML namescope can be used to establish relationships between the XAML-defined names of objects and their instance equivalents in an object tree. Typically, XAML namescopes in [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] managed code are created when loading the individual XAML page roots for a XAML application. XAML namescopes as the programming object are defined by the <xref:System.Windows.Markup.INameScope> interface and are also implemented by the practical class <xref:System.Windows.NameScope>.
XAML namescopes are a concept that identifies objects that are defined in XAML. The names in a XAML namescope can be used to establish relationships between the XAML-defined names of objects and their instance equivalents in an object tree. Typically, XAML namescopes in WPF managed code are created when loading the individual XAML page roots for a XAML application. XAML namescopes as the programming object are defined by the <xref:System.Windows.Markup.INameScope> interface and are also implemented by the practical class <xref:System.Windows.NameScope>.
<a name="Namescopes_in_Loaded_XAML_Applications"></a>
## Namescopes in Loaded XAML Applications
In a broader programming or computer science context, programming concepts often include the principle of a unique identifier or name that can be used to access an object. For systems that use identifiers or names, the namescope defines the boundaries within which a process or technique will search if an object of that name is requested, or the boundaries wherein uniqueness of identifying names is enforced. These general principles are true for XAML namescopes. In WPF, XAML namescopes are created on the root element for a XAML page when the page is loaded. Each name specified within the XAML page starting at the page root is added to a pertinent XAML namescope.
In WPF XAML, elements that are common root elements (such as <xref:System.Windows.Controls.Page>, and <xref:System.Windows.Window>) always control a XAML namescope. If an element such as <xref:System.Windows.FrameworkElement> or <xref:System.Windows.FrameworkContentElement> is the root element of the page in markup, a [!INCLUDE[TLA2#tla_xaml](../../../includes/tla2sharptla-xaml-md.md)] processor adds a <xref:System.Windows.Controls.Page> root implicitly so that the <xref:System.Windows.Controls.Page> can provide a working XAML namescope.
In WPF XAML, elements that are common root elements (such as <xref:System.Windows.Controls.Page>, and <xref:System.Windows.Window>) always control a XAML namescope. If an element such as <xref:System.Windows.FrameworkElement> or <xref:System.Windows.FrameworkContentElement> is the root element of the page in markup, a XAML processor adds a <xref:System.Windows.Controls.Page> root implicitly so that the <xref:System.Windows.Controls.Page> can provide a working XAML namescope.
> [!NOTE]
> WPF build actions create a XAML namescope for a XAML production even if no `Name` or `x:Name` attributes are defined on any elements in the [!INCLUDE[TLA2#tla_xaml](../../../includes/tla2sharptla-xaml-md.md)] markup.
> WPF build actions create a XAML namescope for a XAML production even if no `Name` or `x:Name` attributes are defined on any elements in the XAML markup.
If you try to use the same name twice in any XAML namescope, an exception is raised. For WPF XAML that has code-behind and is part of a compiled application, the exception is raised at build time by WPF build actions, when creating the generated class for the page during the initial markup compile. For XAML that is not markup-compiled by any build action, exceptions related to XAML namescope issues might be raised when the XAML is loaded. XAML designers might also anticipate XAML namescope issues at design time.
@@ -33,7 +33,7 @@ XAML namescopes are a concept that identifies objects that are defined in XAML.
If you call <xref:System.Windows.FrameworkElement.RegisterName%2A> on an object other than the object that defines the XAML namescope, the name is still registered to the XAML namescope that the calling object is held within, as if you had called <xref:System.Windows.FrameworkElement.RegisterName%2A> on the XAML namescope defining object.
### XAML Namescopes in Code
You can create and then use XAML namescopes in code. The APIs and the concepts involved in XAML namescope creation are the same even for a pure code usage, because the XAML processor for [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] uses these APIs and concepts when it processes XAML itself. The concepts and API exist mainly for the purpose of being able to find objects by name within an object tree that is typically defined partially or entirely in XAML.
You can create and then use XAML namescopes in code. The APIs and the concepts involved in XAML namescope creation are the same even for a pure code usage, because the XAML processor for WPF uses these APIs and concepts when it processes XAML itself. The concepts and API exist mainly for the purpose of being able to find objects by name within an object tree that is typically defined partially or entirely in XAML.
For applications that are created programmatically, and not from loaded XAML, the object that defines a XAML namescope must implement <xref:System.Windows.Markup.INameScope>, or be a <xref:System.Windows.FrameworkElement> or <xref:System.Windows.FrameworkContentElement> derived class, in order to support creation of a XAML namescope on its instances.
@@ -45,7 +45,7 @@ XAML namescopes are a concept that identifies objects that are defined in XAML.
<a name="Namescopes_in_Styles_and_Templates"></a>
## XAML Namescopes in Styles and Templates
Styles and templates in [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] provide the ability to reuse and reapply content in a straightforward way. However, styles and templates might also include elements with XAML names defined at the template level. That same template might be used multiple times in a page. For this reason, styles and templates both define their own XAML namescopes, independent of whatever location in an object tree where the style or template is applied.
Styles and templates in WPF provide the ability to reuse and reapply content in a straightforward way. However, styles and templates might also include elements with XAML names defined at the template level. That same template might be used multiple times in a page. For this reason, styles and templates both define their own XAML namescopes, independent of whatever location in an object tree where the style or template is applied.
Consider the following example:
@@ -80,7 +80,7 @@ XAML namescopes are a concept that identifies objects that are defined in XAML.
<xref:System.Windows.ResourceDictionary> does not use XAML names or namescopes ; it uses keys instead, because it is a dictionary implementation. The only reason that <xref:System.Windows.ResourceDictionary> implements <xref:System.Windows.Markup.INameScope> is so it can raise exceptions to user code that help clarify the distinction between a true XAML namescope and how a <xref:System.Windows.ResourceDictionary> handles keys, and also to assure that XAML namescopes are not applied to a <xref:System.Windows.ResourceDictionary> by parent elements.
<xref:System.Windows.FrameworkTemplate> and <xref:System.Windows.Style> implement <xref:System.Windows.Markup.INameScope> through explicit interface definitions. The explicit implementations allow these XAML namescopes to behave conventionally when they are accessed through the <xref:System.Windows.Markup.INameScope> interface, which is how XAML namescopes are communicated by [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] internal processes. But the explicit interface definitions are not part of the conventional API surface of <xref:System.Windows.FrameworkTemplate> and <xref:System.Windows.Style>, because you seldom need to call the <xref:System.Windows.Markup.INameScope> methods on <xref:System.Windows.FrameworkTemplate> and <xref:System.Windows.Style> directly, and instead would use other API such as <xref:System.Windows.FrameworkElement.GetTemplateChild%2A>.
<xref:System.Windows.FrameworkTemplate> and <xref:System.Windows.Style> implement <xref:System.Windows.Markup.INameScope> through explicit interface definitions. The explicit implementations allow these XAML namescopes to behave conventionally when they are accessed through the <xref:System.Windows.Markup.INameScope> interface, which is how XAML namescopes are communicated by WPF internal processes. But the explicit interface definitions are not part of the conventional API surface of <xref:System.Windows.FrameworkTemplate> and <xref:System.Windows.Style>, because you seldom need to call the <xref:System.Windows.Markup.INameScope> methods on <xref:System.Windows.FrameworkTemplate> and <xref:System.Windows.Style> directly, and instead would use other API such as <xref:System.Windows.FrameworkElement.GetTemplateChild%2A>.
The following classes define their own XAML namescope, by using the <xref:System.Windows.NameScope?displayProperty=nameWithType> helper class and connecting to its XAML namescope implementation through the <xref:System.Windows.NameScope.NameScope%2A?displayProperty=nameWithType> attached property: