2009-11-25 20 views
11

me gustaría acceder programáticamente recursos estáticos tanto como lo haría en XAML:Programatically acceder a un recurso estático Silverlight

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

Esto funciona si mi recurso estático se define en el TextBlock, algún elemento de los padres (por ejemplo, control de usuario) o incluso la aplicación. Parece que la expresión de enlace StaticResource sabe cómo recorrer el árbol de elementos o el elemento en sí. Me gustaría hacer lo mismo mediante programación:

<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! 
    } 
} 

Incluso en esta sencilla prueba, parece que no puede tener acceso mediante programación a mi recurso. Y esta es la versión simplificada de lo que estaba tratando de hacer realmente: encontrar un recurso estático a través de un elemento al que tengo una propiedad dinámica personalizada asociada (por ejemplo, uiElement.Resources [key]).

+0

Cuando eliminé los "puntos" de mi clave (por ejemplo, "MyTestKey" en lugar de "My.Test.Key", pude comenzar a ver mis recursos de forma programática. ¿Existe una regla sobre el nombramiento de recursos en XAML o código? -detrás? – Trinition

Respuesta

17

A pesar de su comentario en sentido contrario, dudo del uso de "." en su clave de recursos es realmente la fuente de su problema. En esta situación, el "." no tiene un significado especial y no afectaría la forma en que se accede al recurso. (He intentado y no he podido reproducir ningún problema con él).

Aunque hay una gran diferencia entre el uso de la extensión de marca {StaticResource MyName} y un intento de encontrar el recurso mediante programación.

La extensión de marcado hace que XamlParser busque la clave especificada en la propiedad Resources del FrameworkElement al que pertenece la propiedad que se le asigna. Si no se encuentra la clave, la busca en el elemento primario FrameworkElement y continúa hasta llegar a la raíz FrameworkElement. Si aún no se encuentra, tiene un aspecto en la propiedad Recursos de la aplicación.

Por otro lado este código: -

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

sf simplemente buscando en la propiedad única de Recursos para el control de usuario. No se intenta cazar la clave en antepasados ​​o en los recursos de la aplicación. Es una búsqueda del diccionario simple. Sospecho que esto es lo que realmente te estaba molestando.

Habiendo dicho esto, yo diría que el uso de "." en una clave de recurso puede no ser una buena idea. Los "." tiene sentido en varios escenarios XAML, por lo que usarlo en nombres clave también puede confundir a un desarrollador que lee el código, aunque Silverlight esté bastante satisfecho con él.

+0

Su respuesta es la respuesta directa que estaba buscando: XAML-parse-time look es jerárquico, mientras que el acceso a recursos de programación no lo es. Me gustaría que la lógica jerárquica que usa el analizador XAML también estuviera expuesta para uso programático. , sin embargo, No estoy seguro de que los puntos fueran un problema, tampoco. Y los puntos SI causan un problema para ReSharper: confunde su resaltado de sintaxis Mi intención es utilizar puntos para separar mejor los recursos en pseudo- espacios de nombres para que cada uno de mis módulos de Prism pueda definir recursos y no ejecutar en coll isiones con otros módulos. – Trinition

Cuestiones relacionadas