ComponentResourceKey Markup-tillägg
Definierar och refererar till nycklar för resurser som läses in från externa sammansättningar. Detta gör att en resurssökning kan ange en måltyp i en sammansättning i stället för en explicit resursordlista i en sammansättning eller i en klass.
XAML-attributanvändning (inställningsnyckel, kompakt)
<object x:Key="{ComponentResourceKey {x:Type targetTypeName}, targetID}" ... />
XAML-attributanvändning (inställningsnyckel, utförlig)
<object x:Key="{ComponentResourceKey TypeInTargetAssembly={x:Type targetTypeName}, ResourceID=targetID}" ... />
XAML-attributanvändning (begär resurs, kompakt)
<object property="{DynamicResource {ComponentResourceKey {x:Type targetTypeName}, targetID}}" ... />
XAML-attributanvändning (begära resurs, utförlig)
<object property="{DynamicResource {ComponentResourceKey TypeInTargetAssembly={x:Type targetTypeName}, ResourceID=targetID}}" ... />
XAML-värden
Värde | Beskrivning |
---|---|
targetTypeName |
Namnet på clr-typen (Public Common Language Runtime) som definieras i resurssammansättningen. |
targetID |
Nyckeln till resursen. När resurserna har letats upp kommer targetID att likna x:Key Directive för resursen. |
Anmärkningar
Som du ser i användningarna ovan finns en {ComponentResourceKey
} markeringstilläggsanvändning på två platser:
Definitionen av en nyckel i en temaresursordlista, som tillhandahålls av en kontrollförfattare.
Åtkomst till en temaresurs från sammansättningen, när du försöker ändra kontrollen men vill använda egenskapsvärden som kommer från resurser som tillhandahålls av kontrollens teman.
För att referera till komponentresurser som kommer från teman rekommenderar vi vanligtvis att du använder {DynamicResource}
i stället för att {StaticResource}
. Detta visas i användningarna.
{DynamicResource}
rekommenderas eftersom själva temat kan ändras av användaren. Om du vill att den komponentresurs som bäst matchar kontrollförfattarens avsikt att stödja ett tema ska du också göra komponentresursreferensen dynamisk.
TypeInTargetAssembly identifierar en typ som finns i målsammansättningen där resursen faktiskt definieras. En ComponentResourceKey
kan definieras och användas oberoende av att veta exakt var TypeInTargetAssembly definieras, men måste slutligen lösa typen genom refererade samlingar.
En vanlig användning för ComponentResourceKey är att definiera nycklar som sedan exponeras som medlemmar i en klass. För den här användningen använder du ComponentResourceKey-klasskonstruktorn, inte markeringstillägget. Mer information finns i ComponentResourceKey, eller avsnittet "Definiera och referera till nycklar för temaresurser" i avsnittet Control Authoring Overview.
För både upprättande av nycklar och referens till nycklade resurser används attributsyntax ofta för ComponentResourceKey
markup-tillägg.
Den kompakta syntax som visas bygger på ComponentResourceKey konstruktorsignatur och positionsparameteranvändning för ett markeringstillägg. I vilken ordning targetTypeName
och targetID
anges är viktigt. Den utförliga syntaxen förlitar sig på den ComponentResourceKey parameterlösa konstruktorn och anger sedan TypeInTargetAssembly och ResourceId på ett sätt som motsvarar en sann attributsyntax för ett objektelement. I den utförliga syntaxen är den ordning i vilken egenskaperna anges inte viktig. Relationen och mekanismerna för dessa två alternativ (kompakta och utförliga) beskrivs mer detaljerat i avsnittet Markup Extensions och WPF XAML.
Tekniskt sett kan värdet för targetID
vara vilket objekt som helst, det behöver inte vara en sträng. Den vanligaste användningen i WPF är dock att justera targetID
-värdet med formulär som är strängar och där sådana strängar är giltiga i XamlName Grammar.
ComponentResourceKey
kan användas i objektelementsyntax. I det här fallet krävs det att du anger värdet för både TypeInTargetAssembly och ResourceId egenskaper för att initiera tillägget korrekt.
I WPF XAML-läsarimplementeringen definieras hanteringen för det här påläggstillägget av klassen ComponentResourceKey.
ComponentResourceKey
är ett markup-tillägg. Markeringstillägg implementeras vanligtvis när det finns ett krav på att escape-attributvärden ska vara andra än literalvärden eller hanterarnamn, och kravet är mer globalt än att bara placera typkonverterare på vissa typer eller egenskaper. Alla markupextensioner i XAML använder tecknen { och } i attributsyntaxen, vilket är den konvention genom vilken en XAML-processor känner igen att en markupextension måste bearbeta attributet. Mer information finns i Markup Extensions and WPF XAML.
Se även
.NET Desktop feedback