Question

I’ve built a UserControl that extends the functionality of the ComboBox in interesting and useful ways. It looks like this when it’s dropped down:

I’ve built a whole bunch of features into the control and they all work smoothly. This leads me to believe that I have something of a clue as to what I’m doing. You’d think it would be a trivial matter to have the UserControl’s style set the editable TextBox’s background brush. In fact, it appears to be freaking impossible. And I’m baffled.

The UserControl’s XAML, extremely abbreviated (you’ll thank me for this), looks like this:

<UserControl x:Class="MyApp.CodeLookupBox" x:Name="MainControl">
    <UserControl.Resources>
       <!-- tons of DataTemplates and Styles, most notably the style that
            contains the control template for the ComboBox -->
    <UserControl.Resources>
    <ComboBox x:Name="ComboBox" 
                   Margin="0" 
                   Style="{DynamicResource ComboBoxStyle1}" 
                   VerticalAlignment="Top"
                   ItemTemplate="{StaticResource GridViewStyleTemplate}"/>
</UserControl>

There’s a lot of code-behind in this control, mostly dependency properties that I use for things like selecting the template that’s used in the dropdown.

What’s making me crazy is the editable text box. I want to be able to set its background brush from the user control’s style – e.g., when I declare one of these user controls in my XAML, it uses a style like this:

<Style TargetType="{x:Type local:CodeLookupBox}">
    <Style.Triggers>
        <DataTrigger Binding="{Binding IsRequired}" Value="True">
            <Setter Property="EditableTextBoxBackground" Value="{StaticResource RequiredFieldBrush}"/>
        </DataTrigger>
    </Style.Triggers>
</Style>

I started out life simply setting the UserControl’s Background, but that set the background behind the editable TextBox. The TextBox itself remained white.

Inside the template for the ComboBox, there’s a style that controls that TextBox:

<Style x:Key="ComboBoxEditableTextBox" TargetType="{x:Type TextBox}">
    <Setter Property="OverridesDefaultStyle" Value="true"/>
    <Setter Property="AllowDrop" Value="true"/>
    <Setter Property="MinWidth" Value="0"/>
    <Setter Property="MinHeight" Value="0"/>
    <Setter Property="FocusVisualStyle" Value="{x:Null}"/>

    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="{x:Type TextBox}">
                <ScrollViewer 
                            x:Name="PART_ContentHost" 
                            Focusable="false" 
                            HorizontalScrollBarVisibility="Hidden" 
                            VerticalScrollBarVisibility="Hidden"/>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

And there is the TextBox (inside the ComboBox’s control template) its bad self:

<TextBox 
    x:Name="PART_EditableTextBox" 
    Margin="{TemplateBinding Padding}" 
    Style="{StaticResource ComboBoxEditableTextBox}" 
    HorizontalContentAlignment="{TemplateBinding HorizontalContentAlignment}" 
    VerticalContentAlignment="{TemplateBinding VerticalContentAlignment}"
    IsReadOnly="{Binding IsReadOnly, RelativeSource={RelativeSource TemplatedParent}}"/>

Now, there’s a definite element of Things Man Was Not Meant To Know about that ComboBoxEditableTextBox style. What is that ScrollViewer doing in there? I have no idea. I can tell you that if I comment out the part of the style that sets the TextBox’s ControlTemplate, very bad things happen.

And I also know this: If I explicitly set the TextBox’s Background brush as one of the style’s setters, nothing happens. If I explicitly set the Background on the PART_EditableTextBox, nothing happens. (I can set its Foreground, or its FontFamily, and they work just fine.)

If I explicitly set the Background of that ScrollViewer to Green, though, voila, the TextBox turns green.

Okay then, so the TextBox is ignoring its own Background, and using the one from its control template. Actually, it’s not, strictly speaking, using the one from the control template either. When I set the ScrollViewer’s background, there’s a decided margin around the edges of the color, instead of the color filling the TextBox entirely. But that margin is white, not the background color.

Unless I can figure out why the TextBox is ignoring its Background, I have to live with tweaking the ScrollViewer. So how do I get it to get the brush from the user control’s EditableTextBoxBackground property? I’ve made this a dependency property that raises the PropertyChanged event properly when it changes. I’m binding to it in the mysterious ScrollViewer’s XAML like this:

Background="{Binding ElementName=MainControl, 
    Path=EditableTextBoxBackground, 
    Converter={StaticResource DebuggingConverter}}"

I’ve set a breakpoint in my debugging converter. When the control is first drawn, it gets hit twice. The first time, the value of the brush is null. The second time, it’s the right value. And if I set the property in my UserControl’s constructor, it works.

So here’s what I know: My UserControl’s property is being set properly. The binding on the TextBox’s style is correctly bound to the UserControl’s property. The binding on the ScrollViewer in the TextBox’s control template is bound to the right property. The property raises PropertyChanged with the right property name when it’s changed, and the binding pushes the value out to the ScrollViewer Background property.

And nothing happens.

So I guess I have a three part question: 1) Why? 2) What the heck is that ScrollViewer doing in there in the first place? I have my suspicions, but it’s one in the morning and it’s getting hard for me to articulate them. 3) Why did Blend give me a different control template to work with than the much more comprehensible one found here?

Really, any help would be appreciated.

Answer 1

You have questions. I have answers.

1- Why is the ScrollViewer’s Background binding behaving so strangely?

When a TextBox is first measured, it instantiates its template. This creates the ScrollViewer. Once the template is applied, the TextBox checks to see if the ScrollViewer‘s Background property currently has a null value. If so, it overwrites it with Background.Transparent. Doing so disconnects your binding.

This is why it works when you set it in the constructor but not later on: The TextBox saw the null value and overwrote it with Background.Transparent, breaking the binding.

2- What is the ScrollViewer doing there anyway?

TextBox is a Control that doesn’t actually handle any of the gory details of text presentation itself – if you browse the visual tree you’ll see that this is handled by another Visual with a name something like “TextView”. TextBox‘s main job is actually to present the border around the textbox and/or allow you to give it a totally new look.

TextBox requires a template with an elemnent named PART_ContentHost which is either a ContentPresenter or a ScrollViewer. If it is a simple ContentPresenter, the internal “TextView” object is simply added to it. If it is a ScrollViewer, the TextBox also wires up some additional functionality such as scrolling text into view when it is focused.

The ScrollViewer‘s purpose in life is to allow the text in the TextBox to scroll horizontally, and also scroll vertically for multiline text boxes.

3- Why did Blend give me a different control template

Blend loads the actual ControlTemplate XAML from the referenced assemblies, in this case PresentationFramework.dll and the associated theme dll for the current system theme. So it will load what is actually being used in the version of NET Framework you have installed. The XAML on the site you linked is just example code, and is not the actual NET Framework XAML.

I added two more relevant questions:

4- Why didn’t setting the TextBox’s Background property work?

None of WPF’s Control subclasses actually implement their Background properties themselves. The Background DependencyProperty is just a named brush that a Control’s template can bind to if it likes. This is just as true for TextBox as for any other Control. The default TextBox template includes a “chrome” object that includes code to display the background, similar to what you might use a border for. Since ComboBox is already displaying its own “chrome”, it uses its own TextBox template that includes the ScrollViewer but not the surrounding chrome. That is why setting the Background property on the TextBox inside a ComboBox has no effect.

5- How do I solve my problem and bind the background color of the TextBox inside the ComboBox

If you’re ok with the white margin you can simply wrap the ScrollViewer inside in a <Border> and set the background on the <Border>. If not, you will have to move the desired background into the chrome supplied in the main ControlTemplate for the ComboBox.