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

dotnet-desktop-guide/framework/wpf/advanced/preview-events.md

@@ -19,9 +19,9 @@ Preview events, also known as tunneling events, are routed events where the dire
  For more information about class handling and how it relates to Preview events see [Marking Routed Events as Handled, and Class Handling](marking-routed-events-as-handled-and-class-handling.md).  
   
 ### Working Around Event Suppression by Controls  
- One scenario where Preview events are commonly used is for composited control handling of input events. Sometimes, the author of the control suppresses a certain event from originating from their control, perhaps in order to substitute a component-defined event that carries more information or implies a more specific behavior. For instance, a [!INCLUDE[TLA#tla_winclient](../../../includes/tlasharptla-winclient-md.md)] <xref:System.Windows.Controls.Button> suppresses <xref:System.Windows.UIElement.MouseLeftButtonDown> and <xref:System.Windows.UIElement.MouseRightButtonDown> bubbling events raised by the <xref:System.Windows.Controls.Button> or its composite elements in favor of capturing the mouse and raising a <xref:System.Windows.Controls.Primitives.ButtonBase.Click> event that is always raised by the <xref:System.Windows.Controls.Button> itself. The event and its data still continue along the route, but because the <xref:System.Windows.Controls.Button> marks the event data as <xref:System.Windows.RoutedEventArgs.Handled%2A>, only handlers for the event that specifically indicated they should act in the `handledEventsToo` case  are invoked.  If other elements towards the root of your application still wanted an opportunity to handle a control-suppressed event, one alternative is to attach handlers in code with `handledEventsToo` specified as `true`. But often a simpler technique is to change the routing direction you handle to be the Preview equivalent of an input event. For instance, if a control suppresses <xref:System.Windows.UIElement.MouseLeftButtonDown>, try attaching a handler for <xref:System.Windows.UIElement.PreviewMouseLeftButtonDown> instead. This technique only works for base element input events such as <xref:System.Windows.UIElement.MouseLeftButtonDown>. These input events use tunnel/bubble pairs, raise both events, and share the event data.  
+ One scenario where Preview events are commonly used is for composited control handling of input events. Sometimes, the author of the control suppresses a certain event from originating from their control, perhaps in order to substitute a component-defined event that carries more information or implies a more specific behavior. For instance, a Windows Presentation Foundation (WPF) <xref:System.Windows.Controls.Button> suppresses <xref:System.Windows.UIElement.MouseLeftButtonDown> and <xref:System.Windows.UIElement.MouseRightButtonDown> bubbling events raised by the <xref:System.Windows.Controls.Button> or its composite elements in favor of capturing the mouse and raising a <xref:System.Windows.Controls.Primitives.ButtonBase.Click> event that is always raised by the <xref:System.Windows.Controls.Button> itself. The event and its data still continue along the route, but because the <xref:System.Windows.Controls.Button> marks the event data as <xref:System.Windows.RoutedEventArgs.Handled%2A>, only handlers for the event that specifically indicated they should act in the `handledEventsToo` case  are invoked.  If other elements towards the root of your application still wanted an opportunity to handle a control-suppressed event, one alternative is to attach handlers in code with `handledEventsToo` specified as `true`. But often a simpler technique is to change the routing direction you handle to be the Preview equivalent of an input event. For instance, if a control suppresses <xref:System.Windows.UIElement.MouseLeftButtonDown>, try attaching a handler for <xref:System.Windows.UIElement.PreviewMouseLeftButtonDown> instead. This technique only works for base element input events such as <xref:System.Windows.UIElement.MouseLeftButtonDown>. These input events use tunnel/bubble pairs, raise both events, and share the event data.  
   
- Each of these techniques has either side effects or limitations. The side effect of handling the Preview event is that handling the event at that point might disable handlers that expect to handle the bubbling event, and therefore the limitation is that it is usually not a good idea to mark the event handled while it is still on the Preview part of the route. The limitation of the `handledEventsToo` technique is that you cannot specify a `handledEventsToo` handler in [!INCLUDE[TLA2#tla_xaml](../../../includes/tla2sharptla-xaml-md.md)] as an attribute, you must register the event handler in code after obtaining an object reference to the element where the handler is to be attached.  
+ Each of these techniques has either side effects or limitations. The side effect of handling the Preview event is that handling the event at that point might disable handlers that expect to handle the bubbling event, and therefore the limitation is that it is usually not a good idea to mark the event handled while it is still on the Preview part of the route. The limitation of the `handledEventsToo` technique is that you cannot specify a `handledEventsToo` handler in XAML as an attribute, you must register the event handler in code after obtaining an object reference to the element where the handler is to be attached.  
   
 ## See also