I want to make sure I understand you before I report an issue. The title of the original post was a bit confusing since controls do not change their Foreground based on their Background. Foreground is an inherited DependencyProperty that if not set on an element is inherited from an ancestor on which it was set. In looking at the xamMaskedEditor and xamTextEditor with regards to foreground, it would seem that there are 2 issues.

First, the xamMaskedEditor's background defaults to the system Window color but the foreground is hard coded to black. The foreground should be bound to the WindowText color.

Second, while the xamTextEditor's Background defaults to the system Window color, the foreground is not set and therefore since Foreground is an inherited dependency property it will inherit the foreground of the ancestor element. Since the Background defaults to WindowBrushKey, the Foreground should default to WindowTextBrushKey. This would be consistent with what the TextBox does.

OK, well the xamTextEditor works well for me doing what it currently does, but this is obviously a fluke because it shouldn't be behaving that way.

I guess the proper way to do this is to base the Foreground of a transparent control (in this case, both xamTextEditor and xamMaskedEditor) on the Background of the containing ancestor.

For my particular case, I used Mole to find out which ancestor was providing the dark background colour and it is Border.  I have put a Binding on the Foreground using a converter class to convert the colour.  This appears to resolve it.  I've attached the solution.

Thanks for your help.  I guess there's still a couple of bugs to resolve on your side, though.

Cheers,

Jason

I think the two issues that I pointed out are bugs and I will submit them. If you are binding the Foreground of the element then these shouldn't affect you as your local value will take precedence.

I'm glad you were able to workaround it for your scenario but I would be careful as that could change should you change the theme or if the other vendor changes the way their template is set up.

From a control vendor perspective, I don't think a control could reliably and generically base/manipulate its own Foreground based on the Background of an ancestor. There are many ways that that can break down:

• The ancestor may change whether that be because the element was retemplated or moved. One would need the equivalent of OnAncestorChanged which is internal in the wpf framework.
• The background of the ancestor may change - the binding would handle that.
• The background of an element between the element and the previously considered ancestor element that was used to obtain the background may have changed in which case the background considered would have changed. Background is not inherited so there would be no notification to know that it changed.
• The background may include a semi-transparent color in which case you would need to consider more than just that color.
• The background could be a different type of brush where there is no single color (e.g. LinearGradient, RadialGradient, DrawingBrush, VisualBrush, ImageBrush, etc.).
• What you see on screen may be the result of the background of a sibling of an ancestor element so just considering the immediate visual ancestor tree would not be sufficient.
• What you see on screen may be the result of an ancestor element handling OnRender as opposed to having a Background property.

Well the template change may be subtle. Maybe they need to put another element in the template (e.g. a panel to contain the current element and another and instead of setting the background on the border they set it on the panel) or maybe during a bug fix they determine that that layer isn't needed and they remove it. These are unlikely but the possibility exists. To most developers changing the internals of an element's default template would not likely be thought of as a breaking change. Maybe that's why FindAncestor isn't even supported in SL.

With regards to a better solution I can't say I've considered it before now but off the top of my head I cannot think of anything better. At least in your case you know the specifics of the situation in which this is occurring so you don't need to worry about lots of those downsides that I mentioned if a control vendor were to try and incorporate such functionality into a control itself. Having the element inherit the foreground and ensuring that when you set the background you set a foreground that takes that into account is another way but then you have to make sure that elements do not set the foreground (explicitly or implicitly in their default styles, etc.) or else the inherited value won't be picked up. If the foreground is set in the default style (as it is in the xamMaskedEditor and TextBox and will be in the xamTextEditor when that bug is addressed) then that would likely mean having to provide a local style for those elements that sets all the property values and setting the OverridesDefaultStyle to true would be needed.

OK, thanks Andrew, and I take your point.  But I would hope that the vendor does not change the way their template is set up for this particular feature on the basis that it could break controls used in its CellEditorTemplate that depend on the template's structure.  I'm not sure if it's right for me to assume this, or for them to take this into consideration.  Maybe it's subjective.

That said, can you think of a better solution to adjust a transparent control's Foreground based on the actual colour of the area immediately behind it?