Dela via

Read-Only Beroendeegenskaper

  • Artikel

I det här avsnittet beskrivs skrivskyddade beroendeegenskaper, inklusive befintliga skrivskyddade beroendeegenskaper och scenarier och tekniker för att skapa en anpassad skrivskyddad beroendeegenskap.

Förutsättningar

Det här avsnittet förutsätter att du förstår de grundläggande scenarierna för att implementera en beroendeegenskap och hur metadata tillämpas på en anpassad beroendeegenskap. Se anpassade beroendeegenskaper och beroendeegenskapsmetadata för mer kontext.

Befintliga beroendeegenskaper för Read-Only

Vissa beroendeegenskaper som definierats i WPF-ramverket (Windows Presentation Foundation) är skrivskyddade. Den typiska orsaken till att ange en skrivskyddad beroendeegenskap är att det här är egenskaper som ska användas för tillståndsbestämning, men där tillståndet påverkas av en mängd olika faktorer, men att bara ange egenskapen till det tillståndet är inte önskvärt ur ett designperspektiv för användargränssnittet. Egenskapen IsMouseOver är till exempel bara visningstillstånd som bestäms av musinmatningen. Alla försök att programmeringsmässigt ange det här värdet genom att kringgå den verkliga musinmatningen skulle vara oförutsägbara och leda till inkonsistens.

På grund av att de inte kan ställas in är skrivskyddade beroendeegenskaper inte lämpliga för många av de scenarier där beroendeegenskaper normalt erbjuder en lösning, såsom databindning, direkt stylingsbar till ett värde, validering, animation och arv. Trots att de inte kan anges har skrivskyddade beroendeegenskaper fortfarande några av de ytterligare funktioner som stöds av beroendeegenskaper i egenskapssystemet. Den viktigaste återstående möjligheten är att den skrivskyddade beroendeegenskapen fortfarande kan användas som en utlösare för egenskaper i en stil. Du kan inte aktivera utlösare med en vanlig CLR-egenskap (Common Language Runtime). det måste vara en beroendeegenskap. Den ovan nämnda egenskapen IsMouseOver är ett perfekt exempel på ett scenario där det kan vara ganska användbart att definiera ett format för en kontroll, där vissa synliga egenskaper som bakgrund, förgrund eller liknande egenskaper för sammansatta element i kontrollen ändras när användaren placerar en mus över någon definierad region i kontrollen. Ändringar i en skrivskyddad beroendeegenskap kan också identifieras och rapporteras av egenskapssystemets inbyggda ogiltighetsprocesser, och detta stöder i själva verket funktionen för egenskapsutlösare internt.

Skapa anpassade beroendeegenskaper för Read-Only

Läs avsnittet ovan om varför skrivskyddade beroendeegenskaper inte fungerar för många typiska beroendeegenskapsscenarier. Men om du har ett lämpligt scenario kanske du vill skapa en egen skrivskyddad beroendeegenskap.

Mycket av processen med att skapa en läs-skyddad beroendeegenskap är densamma som beskrivs i avsnitten Anpassade beroendeegenskaper och Implementera en beroendeegenskap. Det finns tre viktiga skillnader:

  • När du registrerar din egenskap anropar du metoden RegisterReadOnly i stället för den normala Register metoden för egenskapsregistrering.

  • När du implementerar egenskapen CLR "wrapper" kontrollerar du att omslutningen inte har någon uppsättning implementering, så att det inte finns någon inkonsekvens i skrivskyddat tillstånd för den offentliga omslutning som du exponerar.

  • Objektet som returneras av det skrivskyddade registret är DependencyPropertyKey i stället för DependencyProperty. Du bör fortfarande lagra det här fältet som medlem, men vanligtvis skulle du inte göra det till en offentlig medlem av typen.

Oavsett vilket privat fält eller värde du har som understödjer din skrivskyddade beroendeegenskap kan det naturligtvis göras helt skrivbart med vilken logik du bestämmer. Det enklaste sättet att ange egenskapen antingen från början eller som en del av körningslogik är dock att använda egenskapssystemets API:er i stället för att kringgå egenskapssystemet och ställa in det privata säkerhetskopieringsfältet direkt. I synnerhet finns det en signatur för SetValue som accepterar en parameter av typen DependencyPropertyKey. Hur och var du anger det här värdet programmatiskt i din programlogik påverkar hur du kanske vill ange åtkomst för den DependencyPropertyKey som skapades när du först registrerade beroendeegenskapen. Om du hanterar den här logiken i klassen kan du göra den privat, eller om du kräver att den anges från andra delar av sammansättningen kan du ange den internt. En metod är att anropa SetValue i en klasshändelsehanterare för en relevant händelse som informerar en klassinstans om att det lagrade egenskapsvärdet måste ändras. En annan metod är att binda beroendeegenskaper samman genom att använda ihopparade PropertyChangedCallback och CoerceValueCallback återanrop som en del av dessa egenskapers metadata vid registreringen.

Eftersom DependencyPropertyKey är privat och inte sprids av egenskapssystemet utanför din kod, har en skrivskyddad beroendeegenskap bättre säkerhet än en läs- och skrivbar beroendeegenskap. För en läs- och skrivbar beroendeegenskap är det identifierande fältet explicit eller implicit offentligt och därför är egenskapen allmänt förändringsbar. Mer information finns i Dependency Property Security.

Se även