Also with RadListBox, of course. This is using the VisualStudio 2013 theme.
Simple repro:
Create a ListBox with IsEnabled=false.
Add a CheckBox item, with a Content="Testing" or whatever.
Notice that it is very dark, nearly unreadable. It's because in your theme XAML, you have set the RadListBoxItem disabled state contentPresenter to an Opacity of 0.2. Now, inside of a CheckBox, you also have similar code for the disabled state where the content's Opacity is set to 0.2.
Guess what? The 2 values multiply, which means now the CheckBox has an effective Opacity value of 0.2*0.2 = 0.04. :( That's dark.
I can see why this was done, because if your ListBox has strings only, then it works, because a TextBlock doesn't have a disabled state. Yeah, but what if your ItemTemplate has controls that they themselves have a darkened disabled state??? That doubles up the disabled-ness.
I like how Microsoft handles it by changing the Foreground to grey in their themes instead of screwing with Opacity (since Foreground is inherited), and that would work perfectly in both my cases, string-only lists and checkbox lists.
1 Answer, 1 is accepted
We are sorry for the inconvenience caused. The reason we have chosen to achieve the disabled state with opacity is to preserve the foreground of the content - if it is the default one we have set, then good, we could have used a fixed brush, but if it is another one, chosen by the user, the expected behavior would be to preserve the color instead of changing it to something we have hard-coded inside.
Naturally, there are scenarios like this one, where the opacity accumulates, which is extremely annoying especially in dark variations of the themes.
Please, find attached a sample project with a workaround for that - a style for all CheckBoxes that are in a RadListBoxItem. It preserves the look of the RadListBox, its items and CheckBoxes outside it, but fixes the case when CheckBoxes are inside it. (in case you are using ImplicitStyles).
Regards,
Martin
Telerik by Progress