XAML リソースの概要Overview of XAML resources

リソースは、アプリ内のさまざまな場所で再利用できるオブジェクトです。A resource is an object that can be reused in different places in your app. リソースの例として、ブラシやスタイルがあります。Examples of resources include brushes and styles. この概要では、Extensible Application Markup Language (XAML) でのリソースの使用方法について説明します。This overview describes how to use resources in Extensible Application Markup Language (XAML). また、コードを使用して、リソースを作成してアクセスすることもできます。You can also create and access resources by using code.

注意

この記事で説明する XAML リソースは、 "アプリ リソース" とは異なります。アプリ リソースは一般に、コンテンツ、データ、埋め込みファイルなど、アプリに追加されるファイルです。XAML resources described in this article are different from app resources which are generally files added to an app, such as content, data, or embedded files.

重要

デスクトップ ガイド ドキュメントは作成中です。The Desktop Guide documentation is under construction.

XAML でのリソースの使用Using resources in XAML

次の例では、ページのルート要素のリソースとして SolidColorBrush を定義します。The following example defines a SolidColorBrush as a resource on the root element of a page. この例では、次にそのリソースを参照し、それを使用して、EllipseTextBlockButton など、いくつかの子要素のプロパティを設定します。The example then references the resource and uses it to set properties of several child elements, including an Ellipse, a TextBlock, and a Button.

<Page Name="root"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
  <Page.Resources>
    <SolidColorBrush x:Key="MyBrush" Color="Gold"/>
    <Style TargetType="Border" x:Key="PageBackground">
      <Setter Property="Background" Value="Blue"/>
    </Style>
    <Style TargetType="TextBlock" x:Key="TitleText">
      <Setter Property="Background" Value="Blue"/>
      <Setter Property="DockPanel.Dock" Value="Top"/>
      <Setter Property="FontSize" Value="18"/>
      <Setter Property="Foreground" Value="#4E87D4"/>
      <Setter Property="FontFamily" Value="Trebuchet MS"/>
      <Setter Property="Margin" Value="0,40,10,10"/>
    </Style>
    <Style TargetType="TextBlock" x:Key="Label">
      <Setter Property="DockPanel.Dock" Value="Right"/>
      <Setter Property="FontSize" Value="8"/>
      <Setter Property="Foreground" Value="{StaticResource MyBrush}"/>
      <Setter Property="FontFamily" Value="Arial"/>
      <Setter Property="FontWeight" Value="Bold"/>
      <Setter Property="Margin" Value="0,3,10,0"/>
    </Style>
  </Page.Resources>
  <StackPanel>
    <Border Style="{StaticResource PageBackground}">
      <DockPanel>
        <TextBlock Style="{StaticResource TitleText}">Title</TextBlock>
        <TextBlock Style="{StaticResource Label}">Label</TextBlock>
        <TextBlock DockPanel.Dock="Top" HorizontalAlignment="Left" FontSize="36" Foreground="{StaticResource MyBrush}" Text="Text" Margin="20" />
        <Button DockPanel.Dock="Top" HorizontalAlignment="Left" Height="30" Background="{StaticResource MyBrush}" Margin="40">Button</Button>
        <Ellipse DockPanel.Dock="Top" HorizontalAlignment="Left" Width="100" Height="100" Fill="{StaticResource MyBrush}" Margin="40" />
      </DockPanel>
    </Border>
  </StackPanel>
</Page>


すべてのフレームワーク レベルの要素 (FrameworkElementFrameworkContentElement) には、定義されたリソースを含む ResourceDictionary 型の Resources プロパティがあります。Every framework-level element (FrameworkElement or FrameworkContentElement) has a Resources property, which is a ResourceDictionary type that contains defined resources. リソースは、Button など、任意の要素に定義できます。You can define resources on any element, such as a Button. ただし、ほとんどの場合、リソースはルート要素 (例では Page) に定義されます。However, resources are most often defined on the root element, which is Page in the example.

リソース ディクショナリ内の各リソースには、一意のキーが必要です。Each resource in a resource dictionary must have a unique key. マークアップでリソースを定義する場合は、x:Key ディレクティブを使用して一意のキーを割り当てます。When you define resources in markup, you assign the unique key through the x:Key Directive. 通常、キーは文字列です。ただし、適切なマークアップ拡張機能を使用して、他のオブジェクトの型に設定することもできます。Typically, the key is a string; however, you can also set it to other object types by using the appropriate markup extensions. リソースの文字列以外のキーは、WPF の特定の機能領域、特に、スタイル、コンポーネント リソース、データ スタイルに使用されます。Non-string keys for resources are used by certain feature areas in WPF, notably for styles, component resources, and data styling.

定義されたリソースは、リソースのキー名を指定するリソース マークアップ拡張構文で使用できます。You can use a defined resource with the resource markup extension syntax that specifies the key name of the resource. たとえば、リソースを別の要素のプロパティの値として使用します。For example, use the resource as the value of a property on another element.

<Button Background="{StaticResource MyBrush}"/>
<Ellipse Fill="{StaticResource MyBrush}"/>

上記の例では、XAML ローダーで ButtonBackground プロパティの値 {StaticResource MyBrush} が処理されるときに、リソース検索ロジックではまず、Button 要素のリソース ディクショナリが確認されます。In the preceding example, when the XAML loader processes the value {StaticResource MyBrush} for the Background property on Button, the resource lookup logic first checks the resource dictionary for the Button element. Button にリソース キー MyBrush の定義がない場合 (この例では定義がありません。そのリソース コレクションは空です)、検索では次に Button の親要素 (Page) が確認されます。If Button doesn't have a definition of the resource key MyBrush (in that example it doesn't; its resource collection is empty), the lookup next checks the parent element of Button, which is Page. Page ルート要素にリソースを定義すると、Page の論理ツリー内のすべての要素がそれにアクセスできます。If you define a resource on the Page root element, all the elements in the logical tree of the Page can access it. さらに、同じリソースを再利用して、そのリソースが表すものと同じ型を受け入れるプロパティの値を設定できます。And you can reuse the same resource for setting the value of any property that accepts the same type that the resource represents. 前の例では、同じ MyBrush リソースで 2 つの異なるプロパティ (ButtonBackground と、RectangleFill) が設定されています。In the previous example, the same MyBrush resource sets two different properties: the Background of a Button, and the Fill of a Rectangle.

静的および動的なリソースStatic and dynamic resources

リソースは、静的または動的として参照できます。A resource can be referenced as either static or dynamic. 参照は、StaticResource のマークアップ拡張機能または DynamicResource のマークアップ拡張機能を使用して作成します。References are created by using either the StaticResource Markup Extension or the DynamicResource Markup Extension. マークアップ拡張機能は XAML の機能であり、マークアップ拡張機能が属性文字列を処理し、オブジェクトを XAML ローダーに返すことで、オブジェクト参照を指定できるようにします。A markup extension is a XAML feature that lets you specify an object reference by having the markup extension process the attribute string and return the object to a XAML loader. マークアップ拡張機能の動作の詳細については、 「マークアップ拡張機能と WPF XAML」を参照してください。For more information about markup extension behavior, see Markup Extensions and WPF XAML.

マークアップ拡張機能を使用する場合、通常は、その特定のマークアップ拡張機能によって処理される 1 つ以上のパラメーターを文字列形式で指定します。When you use a markup extension, you typically provide one or more parameters in string form that are processed by that particular markup extension. StaticResource のマークアップ拡張機能では、使用可能なすべてのリソース ディクショナリでそのキーの値を検索することでキーが処理されます。The StaticResource Markup Extension processes a key by looking up the value for that key in all available resource dictionaries. 処理は読み込み中に行われます。これは、読み込みプロセスでプロパティ値を割り当てる必要がある場合です。Processing happens during load, which is when the loading process needs to assign the property value. DynamicResource のマークアップ拡張機能では、それに代わり、式を作成してキーが処理されます。この式は、アプリが実行される時点までは未評価のままであり、その時点で式が評価され、値が提供されます。The DynamicResource Markup Extension instead processes a key by creating an expression, and that expression remains unevaluated until the app runs, at which time the expression is evaluated and provides a value.

リソースを参照する場合、静的リソース参照と動的リソース参照のどちらを使用するかに対し、次の考慮事項が影響する可能性があります。When you reference a resource, the following considerations can influence whether you use a static resource reference or a dynamic resource reference:

  • アプリ用リソースの作成方法の全体的な設計 (ページ単位、アプリ内、Loose XAML で、またはリソースのみのアセンブリで) を決定する際は、次の点を考慮してください。When determining the overall design of how you create the resources for your app (per page, in the app, in loose XAML, or in a resource-only assembly), consider the following:

  • アプリの機能。The app's functionality. リソースをリアルタイムで更新することは、アプリの要件に含まれていますか。Are updating resources in real-time part of your app requirements?

  • そのリソース参照の種類の、それぞれの検索動作。The respective lookup behavior of that resource reference type.

  • 特定のプロパティまたはリソースの種類と、それらの種類のネイティブ動作。The particular property or resource type, and the native behavior of those types.

静的リソースStatic resources

静的リソース参照は、次のような状況に最適です。Static resource references work best for the following circumstances:

  • アプリの設計で、そのほとんどのリソースがページまたはアプリケーション レベルのリソース ディクショナリに集中している。Your app design concentrates most of its resources into page or application-level resource dictionaries. 静的リソース参照が、ページの再読み込みなどの実行時の動作に基づいて再評価されない。Static resource references aren't reevaluated based on runtime behaviors, such as reloading a page. そのため、リソースやアプリの設計上必要とされない大量の動的リソース参照を回避するという、パフォーマンス上の利点があります。So there can be some performance benefit to avoiding large numbers of dynamic resource references when they aren't necessary based on your resource and app design.

  • DependencyObject にも Freezable にもないプロパティの値を設定しようとしている。You're setting the value of a property that isn't on a DependencyObject or a Freezable.

  • DLL にコンパイルされ、アプリの一部としてパッケージ化、またはアプリ間で共有されるリソース ディクショナリを作成しようとしている。You're creating a resource dictionary that will be compiled into a DLL and packaged as part of the app or shared between apps.

  • カスタム コントロール用のテーマを作成していて、そのテーマ内で使用されるリソースを定義しようとしている。You're creating a theme for a custom control and are defining resources that are used within the themes. この場合は通常、動的リソース参照の検索動作は望ましくありません。代わりに、検索が予測可能になり、テーマに対して自己完結するように、静的リソース参照動作を使用する必要があります。For this case, you typically do not want the dynamic resource reference lookup behavior; you instead want the static resource reference behavior so that the lookup is predictable and self-contained to the theme. 動的リソース参照では、テーマ内の参照でも実行時までは未評価のままになります。With a dynamic resource reference, even a reference within a theme is left unevaluated until run-time. また、場合によっては、テーマが適用されるときに、何らかのローカル要素によって、テーマで参照が試みられているキーが再定義され、検索でテーマ自体より前にそのローカル要素が失敗します。and there is a chance that when the theme is applied, some local element will redefine a key that your theme is trying to reference, and the local element will fall prior to the theme itself in the lookup. これが起こると、テーマは想定どおりに動作しません。If that happens, your theme will not behave as expected.

  • リソースを使用して、多数の依存関係プロパティを設定しようとしている。You're using resources to set large numbers of dependency properties. 依存関係プロパティには、プロパティ システムによって有効になる有効値キャッシュがあります。そのため、読み込み時に評価できる依存関係プロパティに値を指定すると、依存関係プロパティは再評価される式を確認する必要がなく、最後の有効値を返すことができます。Dependency properties have effective value caching as enabled by the property system, so if you provide a value for a dependency property that can be evaluated at load time, the dependency property doesn't have to check for a reevaluated expression and can return the last effective value. この手法ではパフォーマンス上の利点が得られる可能性があります。This technique can be a performance benefit.

  • すべてのコンシューマー用の基礎リソースを変更する必要がある、または x:Shared 属性を使用してコンシューマーごとに別個の書き込み可能インスタンスを保持する必要がある。You want to change the underlying resource for all consumers, or you want to maintain separate writable instances for each consumer by using the x:Shared Attribute.

静的リソースの検索動作Static resource lookup behavior

静的リソースがプロパティまたは要素によって参照されるときに自動的に行われる検索プロセスについて、下記で説明します。The following describes the lookup process that automatically happens when a static resource is referenced by a property or element:

  1. 検索プロセスでは、プロパティを設定する要素によって定義されたリソース ディクショナリ内で、要求されたキーが確認されます。The lookup process checks for the requested key within the resource dictionary defined by the element that sets the property.

  2. 検索プロセスでは次に、親要素とそのリソース ディクショナリに向かって、論理ツリーが上方向に走査されます。The lookup process then traverses the logical tree upward to the parent element and its resource dictionary. このプロセスは、ルート要素に到達するまで続けられます。This process continues until the root element is reached.

  3. アプリ リソースが確認されます。App resources are checked. アプリ リソースとは、WPF アプリの Application オブジェクトによって定義されたリソース ディクショナリ内のリソースのことです。App resources are those resources within the resource dictionary that is defined by the Application object for your WPF app.

リソース ディクショナリ内からの静的リソース参照では、リソース参照の前に既に辞書的に定義されているリソースを参照する必要があります。Static resource references from within a resource dictionary must reference a resource that has already been defined lexically before the resource reference. 前方参照は、静的リソース参照では解決できません。Forward references cannot be resolved by a static resource reference. このため、リソースがそれぞれのリソース ディクショナリの先頭または先頭付近で定義されるように、リソース ディクショナリの構造を設計してください。For this reason, design your resource dictionary structure such that resources are defined at or near the beginning of each respective resource dictionary.

静的リソース検索はテーマまたはシステム リソースにまで拡張できますが、この検索は、XAML ローダーによって要求が遅延されるという理由だけでサポートされています。Static resource lookup can extend into themes or into system resources, but this lookup is supported only because the XAML loader defers the request. この遅延は、ページの読み込み時のランタイム テーマがアプリに適切に適用されるようにするために必要です。The deferral is necessary so that the runtime theme at the time the page loads applies properly to the app. ただし、テーマ内、またはシステム リソースとしてのみ存在することがわかっているキーに対する静的リソース参照はお勧めできません。このような参照は、テーマがユーザーによってリアルタイムで変更された場合に再評価されないためです。However, static resource references to keys that are known to only exist in themes or as system resources aren't recommended, because such references aren't reevaluated if the theme is changed by the user in real time. テーマまたはシステム リソースを要求するときは、動的リソース参照の方が信頼性が高くなります。A dynamic resource reference is more reliable when you request theme or system resources. 例外は、テーマ要素自体が別のリソースを要求する場合です。The exception is when a theme element itself requests another resource. これらの参照は、前述の理由で、静的リソース参照でなければなりません。These references should be static resource references, for the reasons mentioned earlier.

静的リソース参照が見つからない場合の例外動作にはさまざまなものがあります。The exception behavior if a static resource reference isn't found varies. リソースが遅延された場合、例外は実行時に発生します。If the resource was deferred, then the exception occurs at runtime. リソースが遅延されなかった場合、例外は読み込み時に発生します。If the resource was not deferred, the exception occurs at load time.

動的リソースDynamic resources

動的リソースは、次の場合に最適です。Dynamic resources work best when:

  • リソース (システム リソースや、その他のユーザー設定可能なリソースを含む) の値が、実行時までわからない条件に依存している。The value of the resource, including system resources, or resources that are otherwise user settable, depends on conditions that aren't known until runtime. たとえば、SystemColorsSystemFonts、または SystemParametersによって公開されるシステム プロパティを参照するセッター値を作成できます。For example, you can create setter values that refer to system properties as exposed by SystemColors, SystemFonts, or SystemParameters. これらの値は最終的にはユーザーとオペレーティング システムのランタイム環境から取得されるため、本当の意味で動的です。These values are truly dynamic because they ultimately come from the runtime environment of the user and operating system. また、変更される可能性のあるアプリケーションレベルのテーマを使用している場合もあります。この場合、ページレベルのリソースへのアクセスでもその変更を取り込む必要があります。You might also have application-level themes that can change, where page-level resource access must also capture the change.

  • カスタム コントロールのテーマ スタイルを作成または参照している。You're creating or referencing theme styles for a custom control.

  • アプリの有効期間中に ResourceDictionary の内容を調整するつもりである。You intend to adjust the contents of a ResourceDictionary during an app lifetime.

  • 相互依存関係を含む複雑なリソース構造を使用していて、前方参照が必要になる可能性がある。You have a complicated resource structure that has interdependencies, where a forward reference may be required. 前方参照は静的リソース参照ではサポートされません。ただし、動的リソース参照ではサポートされます。この理由は、リソースは実行時まで評価される必要がなく、前方参照が重要性の高い概念ではないためです。Static resource references do not support forward references, but dynamic resource references do support them because the resource doesn't need to be evaluated until runtime, and forward references are therefore not a relevant concept.

  • コンパイルまたは作業セットの観点では大規模であるリソースを参照していて、そのリソースはページの読み込み時にすぐに使用されない可能性がある。You're referencing a resource that is large from the perspective of a compile or working set, and the resource might not be used immediately when the page loads. 静的リソース参照は常に、ページの読み込み時に XAML から読み込まれます。Static resource references always load from XAML when the page loads. しかし、動的リソース参照は、使用されるまで読み込まれません。However, a dynamic resource reference doesn't load until it's used.

  • セッター値がテーマやその他のユーザー設定に影響される他の値から取得される可能性のあるスタイルを作成しようとしている。You're creating a style where setter values might come from other values that are influenced by themes or other user settings.

  • アプリの有効期間中に論理ツリー内で親が変更される可能性のある要素にリソースを適用しようとしている。You're applying resources to elements that might be reparented in the logical tree during app lifetime. 親を変更するとリソース検索スコープも変更される可能性があるため、親が変更された要素のリソースが新しいスコープに基づいて再評価されるようにする場合は、常に動的リソース参照を使用してください。Changing the parent also potentially changes the resource lookup scope, so if you want the resource for a reparented element to be reevaluated based on the new scope, always use a dynamic resource reference.

動的リソースの検索動作Dynamic resource lookup behavior

動的リソース参照でのリソース検索動作は、FindResource または SetResourceReferenceを呼び出す場合のコード内での検索動作に似ています。Resource lookup behavior for a dynamic resource reference parallels the lookup behavior in your code if you call FindResource or SetResourceReference:

  1. 検索では、プロパティを設定する要素によって定義されたリソース ディクショナリ内で、要求されたキーが確認されます。The lookup checks for the requested key within the resource dictionary defined by the element that sets the property:

  2. 検索では、親要素とそのリソース ディクショナリに向かって、論理ツリーが上方向に走査されます。The lookup traverses the logical tree upward to the parent element and its resource dictionary. このプロセスは、ルート要素に到達するまで続けられます。This process continues until the root element is reached.

  3. アプリ リソースが確認されます。App resources are checked. アプリ リソースとは、WPF アプリの Application オブジェクトによって定義されたリソース ディクショナリ内のリソースのことです。App resources are those resources within the resource dictionary that are defined by the Application object for your WPF app.

  4. テーマのリソース ディクショナリは、現在アクティブなテーマについて確認されます。The theme resource dictionary is checked for the currently active theme. 実行時にテーマが変更された場合、値は再評価されます。If the theme changes at runtime, the value is reevaluated.

  5. システム リソースが確認されます。System resources are checked.

例外の動作 (存在する場合) にはさまざまなものがあります。Exception behavior (if any) varies:

  • リソースが FindResource 呼び出しによって要求され、見つからなかった場合、例外がスローされます。If a resource was requested by a FindResource call and was not found, an exception is thrown.

  • リソースが TryFindResource 呼び出しによって要求され、見つからなかった場合、例外はスローされず、戻り値は null になります。If a resource was requested by a TryFindResource call and was not found, no exception is thrown, and the returned value is null. 設定するプロパティで null が受け入れられない場合でも、設定対象の個々のプロパティに応じて、より深刻な例外がスローされる可能性があります。If the property being set doesn't accept null, then it's still possible that a deeper exception will be thrown, depending on the individual property being set.

  • リソースが XAML の動的リソース参照によって要求され、見つからなかった場合、その動作は一般的なプロパティ システムによって決まります。If a resource was requested by a dynamic resource reference in XAML and was not found, then the behavior depends on the general property system. 一般的な動作は、リソースが存在するレベルでプロパティ設定操作が行われなかった場合と同様です。The general behavior is as if no property setting operation occurred at the level where the resource exists. たとえば、評価できなかったリソースを使用して個別のボタン要素の背景を設定しようとすると、値は設定されませんが、プロパティ システムの他の参加項目から値の優先順位で有効な値を取得できます。For instance, if you attempt to set the background on an individual button element using a resource that could not be evaluated, then no value set results, but the effective value can still come from other participants in the property system and value precedence. たとえば、背景値は、ローカルに定義されたボタン スタイルまたはテーマ スタイルから取得される可能性があります。For instance, the background value might still come from a locally defined button style or from the theme style. テーマ スタイルによって定義されていないプロパティの場合、リソースの評価に失敗した後の有効な値は、プロパティ メタデータの既定値から取得される可能性があります。For properties that aren't defined by theme styles, the effective value after a failed resource evaluation might come from the default value in the property metadata.

制約Restrictions

動的リソース参照には、注意が必要な制約がいくつか存在します。Dynamic resource references have some notable restrictions. 次の条件のうち、少なくとも 1 つが満たされている必要があります。At least one of the following conditions must be true:

設定するプロパティは DependencyProperty または Freezable プロパティでなければならないため、ほとんどのプロパティ変更が UI に反映される可能性があります。プロパティの変更 (動的リソース値の変更) はプロパティ システムによって確認されるためです。Because the property being set must be a DependencyProperty or Freezable property, most property changes can propagate to the UI because a property change (the changed dynamic resource value) is acknowledged by the property system. ほとんどのコントロールには、DependencyProperty が変更され、そのプロパティがレイアウトに影響する可能性がある場合に、コントロールの別のレイアウトを強制的に適用するロジックが組み込まれています。Most controls include logic that will force another layout of a control if a DependencyProperty changes and that property might affect layout. ただし、DynamicResource のマークアップ拡張機能を値として含むすべてのプロパティで、UI のリアルタイム更新が確実に行われるわけではありません。However, not all properties that have a DynamicResource Markup Extension as their value are guaranteed to provide real time updates in the UI. この機能は、プロパティに応じて、およびプロパティを所有する型に応じて、または場合によってはアプリの論理構造に応じて異なる可能性があります。That functionality still might vary depending on the property, as well as depending on the type that owns the property, or even the logical structure of your app.

スタイル、DataTemplates、暗黙的なキーStyles, DataTemplates, and implicit keys

ResourceDictionary 内のすべての項目にキーが必要ですが、それは、すべてのリソースに明示的な x:Key が必要であることを意味するわけではありません。Although all items in a ResourceDictionary must have a key, that doesn't mean that all resources must have an explicit x:Key. リソースとして定義されている場合、いくつかのオブジェクトの型で暗黙的なキーがサポートされます。その場合、キーの値は、別のプロパティの値に関連付けられます。Several object types support an implicit key when defined as a resource, where the key value is tied to the value of another property. この種類のキーが暗黙的なキーと呼ばれます。それに対し、x:Key 属性は明示的なキーです。This type of key is known as an implicit key, whereas an x:Key attribute is an explicit key. 暗黙的なキーを上書きするには、明示的なキーを指定します。You can overwrite any implicit key by specifying an explicit key.

リソースの重要シナリオの 1 つに、Style を定義する場合が挙げられます。One important scenario for resources is when you define a Style. 事実、Style はほとんどの場合、リソース ディクショナリ内のエントリとして定義されます。スタイルが本来、再利用を目的としているためです。In fact, a Style is almost always defined as an entry in a resource dictionary, because styles are inherently intended for reuse. スタイルの詳細については、「スタイルとテンプレート」を参照してください。For more information about styles, see Styling and Templating.

コントロールのスタイルは、暗黙的なキーを使用して作成と参照の両方を行うことができます。Styles for controls can be both created with and referenced with an implicit key. コントロールの既定の外観を定義するテーマ スタイルは、この暗黙的なキーに依存しています。The theme styles that define the default appearance of a control rely on this implicit key. それを要求する側の観点では、暗黙的なキーはコントロール自体の Type です。From the standpoint of requesting it, the implicit key is the Type of the control itself. リソースを定義する側の観点では、暗黙的なキーはスタイルの TargetType です。From the standpoint of defining the resources, the implicit key is the TargetType of the style. したがって、カスタム コントロールのテーマを作成する場合、または既存のテーマ スタイルと相互に作用するスタイルを作成する場合は、その Style に対して x:Key ディレクティブを指定する必要はありません。Therefore, if you're creating themes for custom controls or creating styles that interact with existing theme styles, you do not need to specify an x:Key Directive for that Style. また、テーマ スタイルを使用する場合に、スタイルを指定する必要はいっさいありません。And if you want to use the themed styles, you do not need to specify any style at all. たとえば、Style リソースにキーがないように見える場合でも、次のスタイル定義は機能します。For instance, the following style definition works, even though the Style resource doesn't appear to have a key:

<Style TargetType="Button">
  <Setter Property="Background">
    <Setter.Value>
      <LinearGradientBrush>
        <GradientStop Offset="0.0" Color="AliceBlue"/>
        <GradientStop Offset="1.0" Color="Salmon"/>           
      </LinearGradientBrush>
    </Setter.Value>
  </Setter>  
  <Setter Property="FontSize" Value="18"/>
</Style>

このスタイルには実際にはキー、つまり暗黙的なキー typeof(System.Windows.Controls.Button) があります。That style really does have a key: the implicit key typeof(System.Windows.Controls.Button). マークアップでは、TargetType を型名として直接指定して (または、必要に応じて {x:Type...} を使用して)、In markup, you can specify a TargetType directly as the type name (or you can optionally use {x:Type...} Type が返されるようにすることができます。to return a Type.

WPF によって使用される既定のテーマ スタイル メカニズムを通じて、そのスタイルは、ページに Button のランタイム スタイルとして適用されます。これは、その Button 自体で、スタイルに対するその Style プロパティまたは特定のリソース参照の指定が試みられない場合でも行われます。Through the default theme style mechanisms used by WPF, that style is applied as the runtime style of a Button on the page, even though the Button itself doesn't attempt to specify its Style property or a specific resource reference to the style. ページで定義されたスタイルは、テーマ ディクショナリ スタイルが持つキーと同じキーを使用して、検索シーケンス内でテーマ ディクショナリ スタイルより早く見つけられます。Your style defined in the page is found earlier in the lookup sequence than the theme dictionary style, using the same key that the theme dictionary style has. ページ内の任意の場所で <Button>Hello</Button> を指定するだけで、ButtonTargetType によって定義したスタイルがそのボタンに適用されます。You could just specify <Button>Hello</Button> anywhere in the page, and the style you defined with TargetType of Button would apply to that button. 必要であれば、マークアップを明確にするために、TargetType と同じ型の値を持つスタイルに明示的にキーを付けることもできますが、これは任意です。If you want, you can still explicitly key the style with the same type value as TargetType for clarity in your markup, but that is optional.

OverridesDefaultStyletrue の場合、スタイルの暗黙的なキーはコントロールに適用されません。Implicit keys for styles do not apply on a control if OverridesDefaultStyle is true. (OverridesDefaultStyle は、コントロールのインスタンスで明示的に設定されるのではなく、コントロール クラスのネイティブ動作の一部として設定される場合があることにも注意してください。)また、派生クラスのシナリオで暗黙的なキーをサポートするには、コントロールで DefaultStyleKey がオーバーライドされる必要があります (WPF の一部として提供される既存のすべてのコントロールにこのオーバーライドが含まれています)。(Also note that OverridesDefaultStyle might be set as part of native behavior for the control class, rather than explicitly on an instance of the control.) Also, in order to support implicit keys for derived class scenarios, the control must override DefaultStyleKey (all existing controls provided as part of WPF include this override). スタイル、テーマ、コントロールの設計の詳細については、「スタイルの設定が可能なコントロールを設計するためのガイドライン」を参照してください。For more information about styles, themes, and control design, see Guidelines for Designing Stylable Controls.

DataTemplate には暗黙的なキーもあります。DataTemplate also has an implicit key. DataTemplate の暗黙的なキーは、DataType プロパティ値です。The implicit key for a DataTemplate is the DataType property value. DataType は、{x:Type...} を使用して明示的に指定するのではなく、型の名前として指定することもできます。DataType can also be specified as the name of the type rather than explicitly using {x:Type...}. 詳細については、「データ テンプレートの概要」を参照してください。For details, see Data Templating Overview.

関連項目See also