2009-11-25 17 views
11

mi piacerebbe accedere programatically risorse statiche quanto mi sarebbe in XAML:Programatically accedere a una risorsa di Silverlight statico

<TextBlock Text="{Binding Source={StaticResource My.Text.Key}}" /> 

Questo funziona se la mia risorsa statica è definita sulla TextBlock, qualche elemento padre (ad esempio UserControl) o anche l'applicazione. Sembra che l'espressione di legame StaticResource sappia come risalire all'albero degli elementi, o l'elemento stesso. Mi piacerebbe fare la stessa cosa a livello di programmazione:

<UserControl x:Class="MyCustomControl" ...> 
    <UserControl.Resources> 
     <ResourceDictionary> 
      <ResourceDictionary.MergedDictionaries> 
       <ResourceDictionary Source="Resources.xaml"/> <!-- Sets 'My.Text.Key' to System.String 'Hello, World!' --> 
      </ResourceDictionary.MergedDictionaries> 
     </ResourceDictionary> 
    </UserControl.Resources> 
</UserControl> 

public partial class MyCustomControl 
{ 
    public MyCustomControl() 
    { 
     InitializeComponent(); 
     string myCustomValue = this.Resources[MyCustomValue] as string; // myCustomValue becomes null! 
    } 
} 

Anche in questo semplice test, la mia risorsa non riesco a cui accedere programatically. E questa è la versione semplificata di ciò che stavo cercando di fare davvero: trovare una risorsa statica tramite un elemento a cui è associata una proprietà dinamica personalizzata (ad es. UiElement.Resources [chiave]).

+0

Quando ho tolto i "punti" dalla mia chiave (ad esempio "MyTestKey" anziché "My.Test.Key", potrei iniziare a vedere le mie risorse in modo programmatico. Esiste una regola sulla denominazione delle risorse in XAML o codice -behind? – Trinition

risposta

17

Nonostante il tuo commento in contrario dubito dell'uso di "." nella tua risorsa chiave è davvero la fonte del tuo problema. In questa situazione il "." non ha un significato speciale e non influisce sul modo in cui si accede alla risorsa. (Ho provato e non sono riuscito a riprodurre alcun problema con esso).

C'è tuttavia una grande differenza tra l'utilizzo dell'estensione di markup {StaticResource MyName} e il tentativo di trovare la risorsa a livello di programmazione.

L'estensione di markup fa in modo che XamlParser cerchi la chiave specificata la proprietà Resources dello FrameworkElement a cui appartiene la proprietà assegnata. Se la chiave non viene trovata, la cerca nel genitore FrameworkElement e continua fino a quando non raggiunge la radice FrameworkElement. Se non viene ancora trovato, ha un aspetto nella proprietà Risorse dell'applicazione.

D'altra parte di questo codice: -

string myCustomValue = this.Resources[MyCustomValue] as string; 

sf solo guardando nella proprietà singola risorse per il controllo utente. Non viene effettuato alcun tentativo di rintracciare la chiave negli antenati o nelle risorse dell'applicazione. È una semplice ricerca del dizionario. Questo sospetto sia ciò che ti stava veramente facendo inciampare.

Detto questo, direi che l'uso "." in una risorsa chiave potrebbe non essere una buona idea. Il "." ha già un significato in vari scenari XAML, quindi usarlo nei nomi delle chiavi potrebbe anche confondere uno sviluppatore che legge il codice, anche se Silverlight ne è abbastanza soddisfatto.

+0

La tua risposta è la risposta diretta che stavo cercando: l'aspetto delle risorse XAML-parsing-time è gerarchico mentre l'accesso alle risorse progrmatiche non lo è.Vorrei che la logica gerarchica usata dal parser XAML fosse esposta anche per uso programmatico Non sono convinto che i punti fossero un problema, e i punti DO causano un problema per ReSharper: confonde la sua evidenziazione della sintassi La mia intenzione è usare i punti per separare meglio le risorse in pseudo- spazi dei nomi in modo che ciascuno dei miei moduli Prisma possa definire le risorse e non eseguire il coll isioni con altri moduli. – Trinition

Problemi correlati