TextBlock Fourder en cours de réinitialisation à une valeur héritée après la ressource dynamique du dictionnaire fusionné est appliquée

Question

ÉDITER: J'ai pu le reproduire dans une version très dépouillée de l'application. Voici un lien vers le fichier .zip

http://www.mediafire.com/?cn918gi15uph1xe

J'ai le module ajouter la vue à deux régions différentes - la région de la barre d'état le long du sommet est l'endroit où le problème se produit. La partie étrange est que lorsque le même type de vue est ajouté à la région principale, il n'y a aucun problème. La région de la barre d'état est un contrôle des éléments et la région principale est un présentpresenter de contenu. C'est la seule différence.

S'il vous plaît laissez-moi savoir si vous avez un aperçu! Merci.

----- Post original -----

Bonjour à tous,

Je vois un comportement étrange avec WPF. J'utilise .net 4 et Prism V4. La façon dont nous avons structuré notre application est que les dictionnaires des ressources cutanées existent dans leur propre assemblage. Les modules ne font pas référence à cet assemblage - nous avons plutôt une classe Skin Manager qui lit à partir d'un fichier de configuration que nous voulons et charge les composants appropriés dans un dictionnaire fusionné. Le dictionnaire fusionné est défini dans les ressources d'application (nous effacons l'application.Resources.mergeddictionaries avant de l'ajouter). L'idée est que nous pouvons plus tard changer de skins au moment de l'exécution si nécessaire, et les modules n'ont pas besoin de connaître les skins avant l'exécution.

Ensuite, dans notre XAML, nous faisons référence aux styles en utilisant DynamicResource. Le problème a à voir avec un style TextBlock défini dans la peau et référencé par Key, comme

<TextBlock Style="{DynamicResource someKey}" ... />

Le style définit la famille des polices, la taille de la police et le premier plan. La famille et la taille des polices sont appliquées correctement (j'ai vérifié cela). Le premier plan, cependant, est toujours noir. J'ai utilisé Snoop et WPF Inspector pour voir que la valeur de premier plan est "héritée" au lieu de provenir du style.

J'ai également un contrôle qui hérite de TextBlock et tout ce qu'il fait est d'ajouter des propriétés qui déterminent la valeur du texte (cela n'affecte pas du tout le style). J'ai pu ajouter un remplacement modifié de propriété pour la propriété de premier plan et j'ai découvert que la valeur de premier plan du style est appliquée, puis la valeur héritée est appliquée après cela. Je n'ai pas pu faire fonctionner le débogage de la source .NET, donc je ne pouvais pas comprendre pourquoi / où il était appelé à partir de la deuxième fois ...

Voici un lien vers un vieux et vieux post d'un gars avec exactement le même problème - il n'a pas trouvé la réponse, mais plutôt une solution de contournement. Malheureusement, la solution de contournement ne fonctionne que sur le contrôle hérité (je ne peux pas définir l'héritage de la bavine pour TextBlocks).

http://social.msdn.microsoft.com/forums/en-us/wpf/thread/3501ed19-ab40-4064-81b5-e9b7b9d35b56

Answer 1

Cela n'explique pas pourquoi le problème existe, mais un correctif a été trouvé ici:

http://compositewpf.codeplex.com/discussions/257596

Le correctif consiste à charger les peaux avant de créer / ajouter des vues au shell.

Answer 2

Je suppose que pour TextBlock, la propriété de premier plan est héritée de son parent, sauf si vous le définissez explicitement sur votre instane Textblock. Par exemple, si vous modifiez la fenêtre ou UserControl, ce TextBlock est dans un premier plan de bleu? Une chose que vous pouvez essayer de faire est dans le style au lieu de définir simplement Foreground à une couleur, régler TextElement.Foreground. Voyez si cela fonctionne.