possible bug? issue with dynamicresource style foreground value on TextBlock added to ItemsControl region

Topics: Prism v4 - WPF 4
May 14, 2011 at 12:12 AM


I have run into a very strange behavior with WPF .NET 4 and PRISM v4.  When one of our modules adds its view to an ItemsControl region in the shell, the Foreground value of TextBlocks within that view are all set to the default inherited value of the window (Black).  All of the other values set in the TextBlock style are applied correctly, and if I change the region to be a ContentControl (for example) then the issue goes away - and the TextBlocks receive the correct Foreground color from the style.  I'm setting the style on the TextBlock using a DynamicResource markup and the style is defined in a resource dictionary in a separate assembly, which gets loaded at runtime (so no reference to the skin assembly from the other projects).

I did some debugging and found that the style's value is set initially on the TextBlock, however after that the foreground is set a second time to the inherited default value (the ValueSource in the dependency property changed handler indicated "Inherited" and the value was Black).

I was able to strip down our application and reproduce the issue.  Here is a link to download the .zip file from MediaFire:  http://www.mediafire.com/?cn918gi15uph1xe 

I am not sure if this has anything to do with the ItemsControlRegionAdapter and the fact that the ItemsSource is pointing to a list containing the view UserControl?  I am completely stumped, to be honest, and I need to resolve this issue ASAP.

If you are able to try out the sample project, look at line 20 in ShellView.xaml of the Shell project.  Run the app and verify that at the top of the screen is black text (it's difficult to read, sorry - forgot to change the background to a lighter color), and in the center is white text.  Then go back to the ShellView and change the region on line 20 to a ContentControl.  Run the app again, and you will see that both the text at the top and bottom are white - as the style specifies.


May 16, 2011 at 8:52 PM

Hi Valerie,

After debugging your application we’ve found that if you load your skins configuration files before adding the views into Shell´s regions the styles are loaded correctly as you expect.

We modified your App.xaml.cs class like this:

protected override void OnStartup(StartupEventArgs e)
    IUnityContainer Container = new UnityContainer();
    Container.RegisterInstance<IUnityContainer>(Container, new ContainerControlledLifetimeManager());
    Container.RegisterInstance<SkinManager>(Container.Resolve<SkinManager>(), new ContainerControlledLifetimeManager());
    //load skins here…
    // We are good to go, kick off the bootstrapper
    Bootstrapper bootstrapper = new Bootstrapper(Container, () => Container.Resolve<ShellView>());
    // Load the app skin ---> not here...
    while (!((Window)bootstrapper.ShellView).Activate()) { }

Please let me know if this information helps you.


Miguel Bronzovic


May 16, 2011 at 11:12 PM
Edited May 16, 2011 at 11:21 PM

Hi Miguel,

Thank you for the reply.  That does seem to fix the issue, however it would be very beneficial to know why I need to load the skins before loading any views?  Since all of the style setters besides Foreground are correctly applied...  I don't understand what is "wrong" with the code to cause Foreground to get reset.

EDIT:  In other words, I'd like to understand what actually was happening in WPF/PRISM to cause this problem, not just how to fix it :-)



Jul 5, 2011 at 3:01 PM
Edited Jul 5, 2011 at 3:01 PM


i'm experiencing the same issue

no solution found yet

Nov 3, 2011 at 3:54 PM


It seems that the problem when setting the Foreground property happens because the explicit style is not overriding the inherited value of this property in the control. In the following workitem, we provided a sample that isolates this behavior (ForegroundIssueTestIsolated.zip), and found that this problem only appears when adding content to an ItemsControl using its ItemsSource property (i.e., when using the Items property, the Foreground is correctly set). This is also true when removing every Prism component in the sample.

We also found that a similar discussion was started in WPF, MSDN forums. In this thread the user Paul Brown provided another workaround, based on setting the inheritance behavior in the control as follows:

this.InheritanceBehavior = InheritanceBehavior.SkipToAppNext;

This workaround is applied in the aforementioned sample (TextBlockView.xaml.cs file, Line 16).


Agustin Adami