Style.TargetType Style.TargetType Style.TargetType Style.TargetType Property


Gets or sets the type for which the style is intended. TargetType can be used to declare an implicit style resource if there's no resource key specified.

public : TypeName TargetType { get; set; }
TypeName TargetType();

void TargetType(TypeName targettype);
public Type TargetType { get; set; }
Public ReadWrite Property TargetType As Type
<Style TargetType="typeName"/>

Property Value

Type Type

The type of object to which the style is applied. This value is usually set in XAML, not code. See Remarks.


This example creates two styles: one for a TextBlock and one for a TextBox. Each style is applied to two instances of a control to create a uniform appearance for each TextBlock and TextBox. The example sets the FrameworkElement.Style property of each control by referencing the Style as a {StaticResource} markup extension.

<ControlTemplate TargetType="Button">
  <Grid >
      <VisualStateGroup x:Name="CommonStates">


          <!--Take one half second to transition to the PointerOver state.-->
          <VisualTransition To="PointerOver" 
        <VisualState x:Name="Normal" />

        <!--Change the SolidColorBrush, ButtonBrush, to red when the
            Pointer is over the button.-->
        <VisualState x:Name="PointerOver">
            <ColorAnimation Storyboard.TargetName="ButtonBrush" 
                            Storyboard.TargetProperty="Color" To="Red" />
      <SolidColorBrush x:Name="ButtonBrush" Color="Green"/>


A TargetType value is required for all cases where you use or declare a Style. There is no default value. Even a Style that is used as an inline value of the FrameworkElement.Style property requires an explicit TargetType value.

The typical way to specify a TargetType value is through a XAML attribute on the Style element. When set in XAML, the meaning of TargetType and the values you provide take on some aspects of how types are represented in XAML.

For XAML, any prefixes that would be necessary to refer to a type through a XAML element usage should be included in the TargetType attribute value. For example, if a style targets a custom type, which is defined in a code namespace that's mapped to the "local:" prefix, then the TargetType attribute value for that type's style should include that same prefix preceding the type name. This behavior is enabled by built-in string-type conversion behavior in the Windows Runtime XAML parser.

When defining styles for custom types, once you've included a mapping prefix for a TargetType you don't include any prefix in the Property value of any Setter within that Style.

The value you provide for TargetType modifies the lookup behavior for any Setter.Property value you specify within the style. Specifically, the dependency properties that you reference by name for a Setter.Property XAML attribute value are expected to exist on the TargetType type, or on any ancestor class. For example, if the TargetType you specify is Button, and one of the Setter.Property XAML attribute values in the Style is "Background", that resolves to the Control.Background property (Control is three levels above Button in its class inheritance, and Button inherits all properties of Control ). It's typical to specify the TargetType value to be the same UI element names you'd use in typical UI markup, you wouldn't usually name an ancestor class (although that's technically allowed).

If the Style includes a Setter that declares a control template (a value for the Template property), then the TargetType value of the parent Style should match the TargetType value of the contained ControlTemplate element.

Implicit styles

Styles are almost always declared as XAML resources that are shared and applied to each UI element in the app that references that style. In order to be declared as a resource, all XAML elements including the Style elements must have a key within the resources collection that distinguishes each resource for lookup at run-time. The Style element (and also the various template elements such as ControlTemplate ) support a feature called implicit styles. For an implicit style, the value you provide for the TargetType value also serves as the key for that style in its resources collection scope, and you aren't required to specify the x:Key attribute value. (In contrast, most other elements you declare within a resources collection do need an explicit x:Key attribute value and you'd get design-time or parser errors that enforce this.)

A style that's declared using the implicit style then is used as the Style value for any UI element instance that specifically is of the type that matches the TargetType of the implicit style. Controls don't need to reference a style with a Style attribute value and a {StaticResource} markup extension reference to a key to get this behavior, it's implicit behavior if those controls match an existing implicit style's type.

Implicit styles don't apply to elements that are subtypes of the type referenced as the TargetType value. For example, if you declare an implicit style for ToggleButton controls, and your app has CheckBox controls (CheckBox derives from ToggleButton ), the style applies specifically to ToggleButton controls but not to CheckBox controls.

The Windows Runtime defines default implicit styles for every practical UI element that's part of the Windows Runtime API. It has to do this because these styles define the visuals for elements (particularly the templates), and an element with no visuals won't even appear in the UI or participate in layout. All of these implicit styles can be seen in the design-helper XAML file called generic.xaml. The tools you use to edit XAML can copy discrete parts of this file into your app's XAML as the starting point when you edit copies of styles as enabled by the tools. Within the default implicit styles, there are many layers of resource reference, as well as theme support using the {ThemeResource} markup extension and theme-specific brushes or other resources. You can override any implicit style that would otherwise come from the Windows Runtime defines default implicit styles. For more info, see Quickstart: Styling controls and Quickstart: Control templates.

Using TargetType in code

Setting TargetType in code is uncommon. The XAML style system is intended to be used by loading XAML as a resource and having all aspects of a style be ready beforehand. There should be very few scenarios where you would not know info about how to style a control or apply a style until runtime, where there'd be a need to set a TargetType on a Style created or referenced in code.

Getting a TargetType in code is also uncommon, but there are perhaps a few more scenarios where you might be doing this. For example, there might be a set of named Style resources already defined in your XAML. But you might want to double-check that a style you're about to apply to a control has a TargetType value that works for the type of the control you're applying it to. So, you might have code like this:

        private bool VerifyStyle(FrameworkElement scope, String styleKey, Control applyTo)
            Style styleToCheck = scope.Resources[styleKey] as Style;
            if (styleToCheck != null)
                if (styleToCheck.TargetType == applyTo.GetType())
                    // applyTo.Style = styleToCheck;
                    return true;
            return false;


If you are programming using a Microsoft .NET language (C# or Microsoft Visual Basic), the TypeName type projects as System.Type. When programming using C#C#, you usually use the typeof operator to get references to the System.Type of a type based on a type name as a string. In Microsoft Visual Basic, use GetType.

Migration notes

  • If you have used XAML for Windows Presentation Foundation (WPF), then you might have used an x:Type markup extension to fill in any XAML values that take a System.Type. The Windows Runtime XAML parser does not support x:Type. Instead, you should refer to the type by name without using any markup extension, and any necessary XAML-to-backing type conversion is already handled by the built-in conversion behavior in the XAML parser.