2

ThemeInfoファイル内の属性で立ち往生していAssemblyInfo.csます。カスタムコントロールを作成しようとしています。カスタムコントロールは、「MyCustomControls.dll」というdllにあります。さらに、コントロール自体は、「MyAnotherCustomControls.dll」と呼ばれる別のdll内にある別のカスタムコントロールから派生します。

私はMSDNで、ThemeInfoは、コントロールテーマ固有の場所と一般的な特定の場所を担当する2つのパラメーターで宣言する必要があることを読みましたが、「テーマ」と「一般」はわかりません。どうすればこれら2つをよりよく理解できますか？

誰かが私に一から例を説明することができれば、「一般的」とは何か、そして「テーマ」とは何か。さらに、「一般」または「テーマ」をいつ使用するか。これら2つはWPFシステムでどのように使用されていますか？わかりやすい英語での説明が本当に必要なので、MSDNリンクを投稿する場合は時間を節約してください。ThemeInfoに関するmsdnのドキュメントを読みましたが、わかりません。

またThemeInfo、「MyCustomControls.dll」を使用して「MyAnotherCustomControls.dll」で定義された辞書リソースを使用する方法を教えてもらえますか？ThemeInfoだけでそれを行うことも可能ですか、それとも「MyCustomControls.dll」のMergedDirectoriesを処理する必要がありますか？「MyCustomControls.dll」にマージされたディレクトリを追加しなくても「MyAnotherCustomControls.dll」のスタイルキーを使用できるように、WPFシステムがリソースの検索を処理するようにしたいと思います。

4

1 に答える 1

5

私はMSDNで、ThemeInfoは、コントロールテーマ固有の場所と一般的な特定の場所を担当する2つのパラメーターで宣言する必要があることを読みましたが、「テーマ」と「一般」はわかりません。どうすればこれら2つをよりよく理解できますか？

基本的に、WPFフレームワークは、名前がOSテーマ名と一致するxamlリソースを検索します。したがって、「luna.normal.xaml」という青いテーマでXPを実行している場合。その正確な名前のファイルが見つからない場合は、「generic.xaml」を検索します。実際には、OS固有のものと一致するものが見つからない場合は、最初に「classic.xaml」を探し、次にgeneric.xamlを探します。generic.xamlをデフォルトのリソースと考えることができます。

ThemeInfo属性は、これらのリソースが定義されている場所をWPFに通知するだけです。3つのオプションがあります：

  • なし-「テーマ」または「一般」のリソースを提供していません。これは実際には最適化であるため、WPFフレームワークはわざわざそれらを探す必要はありません。通常、これをGenericDictionaryLocationに使用することはありませんが、OSテーマ固有のリソースを定義しない場合（つまり、異なるOSテーマでコントロールの外観を変えたくない場合）は、これをThemeDictionaryLocationに使用できます。通常、コントロールベンダーは、可能なOSテーマごとにリソースディクショナリを定義して、コントロールがそのオペレーティングシステムで実行されている他のコントロールやウィンドウと一致しているように見えるようにします。
  • ExternalAssembly-これは、リソース用に個別のアセンブリを定義していることを意味します。したがって、WPFフレームワークを見ると、 ThemeDictionaryLocationのPresentationFrameworkアセンブリにこれを使用していることがわかります。次に、サポートするOSテーマごとに個別のアセンブリを定義しました（例：PresentationFramework.Aero.dll、PresentationFramework.Luna.dllなど）。検索するアセンブリの名前は、定義するアセンブリの名前にテーマの名前を加えたものです。
  • SourceAssembly-これは、リソースがアセンブリ自体の中で定義されていることを意味します。したがって、そのアセンブリには、リソースディクショナリを含む「themes」フォルダがあります。

コントロールオーサリングに関するMSDNのこの記事は、これに関する情報を提供することについてはそれほど悪くありません。

また、ThemeInfoを使用して、「MyCustomControls.dll」に「MyAnotherCustomControls.dll」で定義された辞書リソースを使用するように指示する方法を教えてもらえますか？ThemeInfoだけでそれを行うことも可能ですか、それとも「MyCustomControls.dll」のMergedDirectoriesを処理する必要がありますか？「MyCustomControls.dll」にマージされたディレクトリを追加しなくても「MyAnotherCustomControls.dll」のスタイルキーを使用できるように、WPFシステムがリソースの検索を処理するようにしたいと思います。

ThemeInfoを使用して、任意のアセンブリでリソースを検索する必要があることをWPFに通知することはできません。カスタムコントロールを定義するときに通常行われるように、 DefaultStyleKeyを設定またはオーバーライドしない場合は、デフォルトのリソースに対してDefaultStyleKeyが設定/オーバーライドされた基本クラスのリソースを引き続き使用する必要があります。

ただし、ローカルのスタイル解像度（つまり、コントロールのStyleプロパティが設定されておらず、WPFが要素が配置されている場所から見て、視覚的/論理的なツリーを上って、暗黙的に影響を与える可能性のあるスタイルを探す場合）に注意してください。要素）は常にキーがクラスの正確なタイプと一致するスタイルを探します。したがって、TargetType（したがってResourceDictionaryに配置されたときのデフォルトのキー）がウィンドウのリソースで定義されたTextBoxであるスタイルがある場合、そのウィンドウ内のすべてのTextBoxインスタンスに影響します（ビジュアルに近いスタイルがない場合）ツリー-つまり、ある祖先の間の要素のリソースで定義されている-またはそのStyleプロパティが設定されている）。ただし、TextBoxから派生したクラス（例：クラスMyTextBox：TextBox）がある場合、そのスタイルを取得/使用することはありません。代わりに、TargetType / Keyがtypeof（MyTextBox）であるスタイルを探します。それをハックする1つの方法は、StyleプロパティをDynamicResourceの基本型に設定することです。例えば

public MyTextBox()
{
  this.SetResourceReference(StyleProperty, typeof(TextBox));
}

基本的に、これは、キー（したがって、x：Keyが設定されていないスタイルのTargetType）が指定されたタイプ（この場合はTextBox）であるスタイルの動的リソースルックアップを実行するコントロールのStyleプロパティにローカル値を設定します。

お気づきのように、別の方法は、基本クラスのアセンブリが定義するテーマごとにアセンブリ内でxamlファイルをローカルに定義してから、packuri表記を使用して基本クラスのアセンブリ内のリソースを参照するResourceDictionaryをMergedDictionariesに追加することです。DefaultStyleKeyを設定する場合は、TargetTypeがクラスのタイプであるスタイルをそれらの各ResourceDictionariesで定義してから、BasedOnをStaticResourceに設定する必要があります。ここで、リソースキーは基本クラスのタイプです。これを行う必要はないようですが。

于 2013-04-19T14:25:31.100 に答える