1. 简单的HeaderedContentControl

上周五收到反馈，在一个contentcontrol的controltemplate中放两个contentpresenter会导致错误。这错误的例子是我以前在博客中分享的headeredcontentcontrol的代码，这个控件是uwp中最简单的控件之一。其最简化的实现代码如下：

public class HeaderedContentControl : ContentControl {
    public HeaderedContentControl() {
        this.DefaultStyleKey = typeof(HeaderedContentControl);
    }

    public object Header {
        get => (object)GetValue(HeaderProperty);
        set => SetValue(HeaderProperty, value);
    }

    public static readonly DependencyProperty HeaderProperty =
        DependencyProperty.Register(nameof(Header), typeof(object), typeof(HeaderedContentControl), new PropertyMetadata(default(object), OnHeaderChanged));

    private static void OnHeaderChanged(DependencyObject obj, DependencyPropertyChangedEventArgs args) {
        var oldValue = (object)args.OldValue;
        var newValue = (object)args.NewValue;
        if (oldValue == newValue)
            return;
        var target = obj as HeaderedContentControl;
        target?.OnHeaderChanged(oldValue, newValue);
    }

    protected virtual void OnHeaderChanged(object oldValue, object newValue) {
    }
}

ControlTemplate如下：

2. 两种错误

这个控件运行起来本应没有错误，但如果不按常规给Header赋值，就会出现重复的内容：

更奇怪的是，如果这样用还会报错：“Value does not fall within the expected range.”

更奇怪的是相同的代码在WPF完全没有问题。看到这两个奇怪的错误，我马上根据多年的经验知道了错误原因。

3. 问题产生的原因及解决方案

第一种错误，看起来是ContentControl将Content赋值给了ControlTemplate中的所有ContentPresenter。而第二种错误印证了这个猜测，因为“Value does not fall within the expected range.”这个错误（中文是“值不再预期范围中”）在我的印象中只会出现在同一个UIElement被重复添加到VisualTree中的情况。

虽然没看过ContentControl的源码，但我了解到如果ContentPresenter在ContentControl的ControlTemplate中，当ContentPresenter的Content为Null时会默认将自己的Content绑定到ContentControl的Content。基于这个猜测我想到几个解决方案。

3.1 使用ContentControl

使用ContentControl代替Header的ContentPresenter是最简单直接的解决方案。我常常用ContentControl代替ContentPresenter，这没什么不好的。（因为在WPF中ContentPresenter比ContentControl少了一大堆文本相关的属性，所以在WPF常常这么做。）

经过测试这个方案能完美解决所有问题，唯一不足是Header用ContentControl，Content用ContentPresenter，破坏了对称的美感，总感觉不太舒服。

3.2 直接使用WindowsCommunityToolkit的HeaderedContentControl

WindowsCommunityToolkit中也提供了HeaderedContentControl，以前我也写过一篇文章吐槽过这个控件。吐槽归吐槽，我对微软还是很信任的，直接使用这个HeaderedContentControl应该不会有什么问题。

事实证明微软提供的HeaderedContentControl可以解决第一个问题，解决不了第二个问题。摸摸我的1020，我对微软的好感度又下降了。（顺便一提黄色1020真是超漂亮）

3.3 改造WindowsCommunityToolkit的HeaderedContentControl

既然WindowsCommunityToolkit的HeaderedContentControl可以解决第一个问题，看起来它应该也意识到这里会产生问题并修复了，那么看看它是怎么解决的。

private const string PartHeaderPresenter = "HeaderPresenter";

protected virtual void OnHeaderChanged(object oldValue, object newValue) {
    SetHeaderVisibility();
}

protected override void OnApplyTemplate() {
    base.OnApplyTemplate();
    SetHeaderVisibility();
}

private void SetHeaderVisibility() {
    if (GetTemplateChild(PartHeaderPresenter) is FrameworkElement headerPresenter) {
        headerPresenter.Visibility = Header != null
            ? Visibility.Visible
            : Visibility.Collapsed;
    }
}

也就是说HeaderedContentControl的Header等于null时索性就不显示headerPresenter，所以第一个问题得到了解决。但我们再看一次产生第二个问题的XAML:

可以看到Header不是为null，而是一个空字符串，也就是说ContentPresenter把空字符串也和null同样处理。将SetHeaderVisibility改为这样就可以解决这个问题：

private void SetHeaderVisibility() {
    if (GetTemplateChild(PartHeaderPresenter) is FrameworkElement headerPresenter) {
        var isEmpty = false;
        if (Header is string headerText)
            isEmpty = string.IsNullOrEmpty(headerText);
        headerPresenter.Visibility = (Header != null && isEmpty == false)
            ? Visibility.Visible
            : Visibility.Collapsed;
    }
}

4. 结语

为求简单我还是推荐第一种解决方案，即改用ContentControl的方案，毕竟用到ContentPresenter的地方那么多，总不能每次都写一大堆代码SetXXXVisibility。

顺便一提同样的代码在WPF完全没有问题，我总是按着WPF的经验写UWP的代码，偶尔还是会翻车。

话说回来，既然HeaderPresenter总是会被赋值的，那么x:DeferLoadStrategy="Lazy"这句根本就完全没起到作用的吧？

5. 参考

WindowsCommunityToolkit_Microsoft.Toolkit.Uwp.UI.Controls