WPF on 寒流の编程笔记

如何正确使用 WPF 中 Application 的 MainWindow 及 ShutdownMode 属性

Tue, 26 May 2026 00:00:00 +0000

提起 MainWindow，很多人的第一反应都是在创建 WPF 项目后，默认生成的那个 MainWindow 类。但其实我们这次要讨论的，是 Application 类中的 MainWindow 属性，或者大家更熟悉的访问方式是 Application.Current.MainWindow。可能有些人还不太清楚，但实际上它也是有一点使用技巧的，尤其是在与 ShutDownMode 配合使用时。

单例模式

首先，这个 MainWindow 属性是一个单例模式的实现，所以我们可以在项目中的任何地方通过 Application.Current.MainWindow 来访问它。这个功能非常方便，尤其是在需要在多个地方访问主窗口的情况下，比如在视图模型中或者其他服务类中。我们可以直接通过 Application.Current.MainWindow 来获取主窗口的引用，而不需要想尽办法来获取或传递它的引用。这样的需求常见于需要在主界面展示消息、弹窗、导航等操作时。

不过这里有一个稍微需要注意的地方，就是虽然它与我们的 MainWindow 类同名，但它本身是一个 Window 类型的属性，所以我们在使用时需要进行类型转换，这样才能拿到我们定义的 MainWindow 类中的特定方法和属性，或者有名字的界面控件。

配合 ShutDownMode 使用

这部分才是我们今天讨论的重点。WPF 开发者在刚入门的时候，可能会理所当然地认为，MainWindow 就一定是 Application.Current.MainWindow 的实例，并且主窗口关闭了，程序就应该退出了，这是天经地义的。但实际上这个事情恐怕没这么简单。

为什么 MainWindow 属性通常就是 MainWindow？

一个简单的 WPF 程序中，我们通常可以在 App.xaml 中看到类似这样的代码：

1
2
3
4
5


<Application x:Class="WpfApp.App"
 ...
 StartupUri="MainWindow.xaml">
 ...
</Application>

这段代码的意思是，当应用程序启动时，自动创建一个 MainWindow 的实例，并将它设置为 Application.Current.MainWindow。所以在这种情况下，MainWindow 属性确实就是我们定义的 MainWindow 类的实例。

或者如果我们不希望 App 自动帮我们创建主窗口，比如我们希望在程序刚开始的时候读取配置，为 DI 容器注册服务，或者做一些其他的初始化工作，我们可能会删掉 App.xaml 中的 StartupUri，并在 App.xaml.cs 的 OnStartup 方法中手动创建主窗口：

1
2
3
4
5
6
7
8


protected override void OnStartup(StartupEventArgs e)
{
 base.OnStartup(e);

 // 这里我们手动创建 MainWindow 实例
 var mainWindow = new MainWindow();
 mainWindow.Show();
}

在这种情况下，我们同样可以通过 Application.Current.MainWindow 来访问这个主窗口，因为 WPF 默认会自动将第一个显示的窗口设置为 MainWindow 属性的值。

ShutdownMode 是什么？

ShutdownMode 是 Application 类中的一个属性，它决定了当应用程序应该退出的条件。它有三个选项：

OnLastWindowClose：当最后一个窗口关闭时，应用程序退出。这是默认值。
OnMainWindowClose：当主窗口关闭时，应用程序退出。
OnExplicitShutdown：只有当调用 Shutdown() 方法时，应用程序才会退出。

虽然它的默认值是 OnLastWindowClose，但实际上往往 OnMainWindowClose 更加符合我们的预期，因为我们通常希望当主窗口关闭时，整个应用程序就退出了，而不需要担心其他窗口是否还在。因此主窗口本身还常常承载着很多善后工作，例如在 Closed 事件中进行资源清理、保存数据和配置等操作。

如果我们在主窗口的 Closed 事件中再去额外调用 Application.Current.Shutdown() 来保证其他窗口也会被关闭，这显然是不高明的。所以更好的做法是，直接将 ShutdownMode 设置为 OnMainWindowClose，这样当主窗口关闭时，整个应用程序就会自动退出了。我们只需要在 App.xaml 或 App.xaml.cs 中显式设置即可。

Info

关于 Application.Current.Shutdown() 方法，还有一些值得提及的细节：

通过调用它来关闭所有窗口，正常情况下是可以触发每个窗口的 Closing 及 Closed 事件的。
如果窗口还订阅了 Closing 事件，那么即便里面有 e.Cancel = true 的代码逻辑，也不会阻止窗口的关闭。
如果在 Closing 事件中抛出了未经捕获的异常，可能会干扰事件链，导致 Closed 事件不被触发。

第一个窗口不是 `MainWindow` 该怎么办？

有时候，主窗口可能并不是第一个弹出的窗口。一个典型的例子是，我们在应用程序启动时，先弹出一个登录窗口，用户登录成功后才显示主窗口。在这种情况下，Application.Current.MainWindow 可能会指向登录窗口，而不是我们真正的主窗口。那么此时我们该如何使用 OnMainWindowClose 来确保主窗口关闭时应用程序退出呢？

一个并不十分优雅，但也足够应付这个问题的方案是，我们先设置 ShutdownMode 为 OnExplicitShutdown，然后在登录窗口关闭后，再将 ShutdownMode 设置为 OnMainWindowClose，并且在登录窗口关闭时手动将主窗口设置为 Application.Current.MainWindow。这样就能保证当主窗口关闭时，应用程序能够正确退出了。比如在 App.xaml.cs 中：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


protected override void OnStartup(StartupEventArgs e)
{
 base.OnStartup(e);

 // 先设置 ShutdownMode 为 OnExplicitShutdown
 this.ShutdownMode = ShutdownMode.OnExplicitShutdown;

 // 显示登录窗口
 var loginWindow = new LoginWindow();
 var result = loginWindow.ShowDialog();

 if (result == true)
 {
 // 登录成功，创建主窗口
 var mainWindow = new MainWindow();
 mainWindow.Show();

 // 将主窗口设置为 MainWindow 属性
 this.MainWindow = mainWindow;

 // 设置 ShutdownMode 为 OnMainWindowClose
 this.ShutdownMode = ShutdownMode.OnMainWindowClose;
 }
 else
 {
 // 登录失败，直接退出应用程序
 this.Shutdown();
 }
}

这个方法不够优雅的地方在于，我们需要在登录窗口关闭后，手动设置 MainWindow 属性，并且多次切换 ShutdownMode 的值，从而让它们两个正确配合。

更优雅的方式

一个更优雅的方式为，我们可以先创建 MainWindow 的实例，并且赋值给 Application.Current.MainWindow，但不立即显示它。然后我们先显示登录窗口，等用户登录成功后，再显示主窗口。这样就能保证 MainWindow 属性始终指向我们真正的主窗口了，同时也不需要频繁切换 ShutdownMode 的值了。比如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


protected override void OnStartup(StartupEventArgs e)
{
 base.OnStartup(e);

 // 先创建 MainWindow 实例，但不显示
 this.MainWindow = new MainWindow();
 this.ShutdownMode = ShutdownMode.OnMainWindowClose;

 // 显示登录窗口（省略判断登录成功的逻辑）
 var loginWindow = new LoginWindow();
 loginWindow.ShowDialog();

 // 登录成功后显示主窗口
 this.MainWindow.Show();
}

但这时候肯定会有人会问：如果登录失败，那么 MainWindow 不就白创建了？尤其是如果 MainWindow 中包含巨量的初始化逻辑，会不会导致很大的开销，甚至让登录窗口都出现不流畅的情况？

如果你有这样的担忧，那么很有可能是因为你的 MainWindow 的实现方式并不合理，尤其是你将初始化逻辑直接放在了构造函数中。一般来说，我们应该将初始化逻辑放在 Loaded 事件中，或者通过一些惰性加载的方式来实现，这样就能避免在创建 MainWindow 实例时就进行大量的初始化工作了。

或者，如果我们的项目采用了 MVVM 模式，那么我们可以将初始化逻辑放在 MainViewModel 中，并在合适的时机（通常仍然是主窗口的 Loaded 事件）调用它。这样同样可以避免上面的担忧。具体的做法可以是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


public partial class MainWindow : Window
{
 public MainWindow()
 {
 InitializeComponent();
 this.Loaded += MainWindow_Loaded;
 }

 private void MainWindow_Loaded(object sender, RoutedEventArgs e)
 {
 // 在这里进行初始化逻辑
 var viewModel = (MainViewModel)this.DataContext;
 viewModel.Initialize();
 }
}

或者如果你不想在 .xaml.cs 文件里面写太多逻辑，还可以用行为库：

1
2
3
4
5
6
7
8
9


<Window ...
 xmlns:i="http://schemas.microsoft.com/xaml/behaviors">
 <i:Interaction.Triggers>
 <i:EventTrigger EventName="Loaded">
 <i:InvokeCommandAction Command="{Binding InitializeCommand}" />
 </i:EventTrigger>
 </i:Interaction.Triggers>
 ...
</Window>

Tip

除了将视图模型中的 Initialize 方法包装为 ICommand 来调用，还可以使用行为库中的 CallMethodAction 来直接调用视图模型中的方法。不过不太推荐这样做，因为 ICommand，尤其是 CommunityToolkit MVVM 中的 AsyncRelayCommand，可以更好地处理异步操作、错误处理和命令状态管理等问题，而直接调用方法则需要我们自己来处理这些细节了。

总结

总的来说，Application.Current.MainWindow 是一个非常方便的属性，可以让我们在项目中的任何地方访问主窗口的实例。但我们需要注意它与 ShutDownMode 的配合使用，尤其是在一些特殊的场景下，比如登录窗口和主窗口的关系。通过合理地设置 ShutdownMode 和正确地初始化主窗口，我们就能确保当主窗口关闭时，整个应用程序能够正确退出了。

原生 WPF 框架中体现出的设计模式

Mon, 11 Aug 2025 00:00:00 +0000

我们在做软件开发时，经常会使用设计模式，比如单例模式、工厂模式、观察者模式等。这些设计模式帮助我们更好地组织代码，提高代码的可维护性和可扩展性。

但是这次我们换一个角度，来看一看框架本身有没有体现出这些设计模式。希望这篇文章可以给大家一个不一样的视角。

观察者模式

对于观察者模式，相信大多数人可能首先会想到的是在 MVVM 模式下，ViewModel 作为数据的提供者，而 View 作为数据的消费者。当 ViewModel 中的数据发生变化时，它会通知所有绑定的 View 进行更新（具体做法为实现 INotifyPropertyChanged 接口，并触发相应的事件）。这种模式使得 View 和 ViewModel 之间的交互变得简单而高效。

但实际上，原生 WPF 就已经充分体现出了观察者模式。对于大多数控件，本身它就提供了两种实现了观察者模式，或者说可以被观察的特性：

事件：控件的事件机制允许开发者注册事件处理程序，从而在特定事件发生时接收通知。例如，当用户点击按钮时，按钮会触发 Click 事件；当用户修改文本框的内容时，文本框会触发 TextChanged 事件。
依赖属性：控件的依赖属性发生变化时，如果有绑定的目标，它会自动通知这些目标进行更新。这种机制使得控件的状态变化能够被及时“观察”到，从而实现了观察者模式的效果。

所以，在 WPF 开发中，观察者模式并不仅仅体现在 MVVM 模式上，它在控件的事件和依赖属性中也得到了充分的体现。

桥接模式

我们简单回顾一下桥接模式大概是怎么一回事：

如果我们的某一个类存在多个维度的变化（比如不同的外观和不同的行为），比如图形类可能有不同的形状（Shape）以及颜色（Color），那么假如我们采用传统的 OOP 的思想，就不可避免地会引入大量的子类，比如 RedRectangle、BlueCircle 等，这显然是不理想的。

此时，我们就可以使用桥接模式将这两个维度分离开来。这样一来，我们就可以独立地对这两个维度进行扩展，而不必相互影响。

这时候我们回来看 WPF，比如 Control 类就包含了多种不同的实现，包括 Button、Label、TextBox 等；同时，它们又都包含 Background、Foreground 等属性，用于控制它们实际的外观。这是否就和我们上面的例子不谋而合了？

所以，WPF 的 Control 类就是一个典型的桥接模式的实现。它将控件的外观（如样式、模板）和行为（如事件、命令）分离开来，使得我们可以独立地对这两个维度进行扩展。当然，体现桥接模式的不仅仅是 Control 类，其他很多控件也都遵循了这一模式。

装饰器模式

装饰器模式（Decorator Pattern）是一种结构性设计模式，它允许在不改变对象自身的情况下，动态地给对象添加一些额外的职责。装饰器模式通常用于遵循开闭原则（对扩展开放，对修改关闭）。

在 WPF 中，装饰器模式的一个典型应用就是附加属性和行为了。通过附加属性，我们可以在不修改原有控件的情况下，为其添加新的功能。例如，我们可以为一个 TextBox 控件添加一个附加属性，用于控制其是否显示占位符文本。

1

<TextBox local:TextBoxHelper.Placeholder="请输入内容" />

在这个例子中，TextBoxHelper 就是一个提供了附加属性的类，它可以为任意 TextBox 控件添加占位符文本（Placeholder）属性。然后我们就可以在 TextBox 的 Style 或 Template 中响应这个附加属性，从而真的为文本框添加占位符。

行为也类似，而且行为本质上也是附加属性，或者说就是依靠附加属性来实现的。所以这里不再赘述。

所以我们可以说，附加属性利用了装饰器模式。不仅如此，其实它还体现出了其他一些设计模式，比如我们开头提到的观察者模式，此外还有享元模式（附加属性与依赖属性为同一类型的控件提供了相同的属性元数据）、中介者模式（比如一些与布局相关的附加属性，如 DockPanel.Dock、Grid.Row 等）等等。

适配器模式

在 WPF 的绑定中，我们常常会利用到值转换器（ValueConverter），它就是适配器模式的典型体现。

这里我们看一个最典型的例子：我们要将一个布尔属性绑定到控件的 Visibility 属性上。为了能够实现源类型（bool）到目标类型（Visibility）的转换，最常见的方式就是借助 BooleanToVisibilityConverter 了：

1
2
3
4
5
6
7


<Window.Resources>
 <BooleanToVisibilityConverter x:Key="BooleanToVisibilityConverter" />
</Window.Resources>

<Grid>
 <TextBlock Text="Hello, World!" Visibility="{Binding IsTextVisible, Converter={StaticResource BooleanToVisibilityConverter}}" />
</Grid>

另外，值转换器不仅体现出了适配器模式，还体现出了一定程度的策略模式。它们把“如何将一个值转换成另一个值”的算法抽象成一个接口（IValueConverter），并通过不同的实现类来提供具体的转换逻辑，这正是策略模式的核心思想——把一系列可互换的算法封装为独立的策略对象，并在运行时根据需要选择使用哪一个策略。

责任链模式

前面我们提到，控件的事件体现出了观察者模式。其实不仅如此，WPF 在传统 C# 事件的基础上，还引入了路由事件（RoutedEvent）这一概念。

路由事件允许事件在控件的视觉树中沿着特定的路径进行传播，这种传播机制使得我们可以在父级控件中处理子级控件的事件，或者反过来。具体要看路由的方式是冒泡（Bubble）还是隧道（Tunnel）。

但不管哪一种方式，我们都可以在事件的处理过程中形成一个责任链。对于这一点，最明显的体现方式就是对于 e.Handled 的使用。比如我们触发了一个鼠标事件，并且希望在某个父级控件中处理这个事件，那么我们可以在到达该控件时将 e.Handled 设置为 true，从而阻止事件继续向上传播。

1
2
3
4
5
6
7
8


private void OnMouseDown(object sender, MouseButtonEventArgs e)
{
 if (sender is Border)
 {
 // 处理边框的鼠标按下事件
 e.Handled = true; // 阻止事件继续向上传播
 }
}

这一操作就和责任链模式不谋而合：我们可以将事件的处理过程看作是一个链条，每个处理节点都可以选择是否将事件继续传递下去，从而形成一个灵活的事件处理机制。

其他设计模式

除了上面这些典型的例子外，WPF 还体现出了很多其他的设计模式，比如：

状态模式：控件的视觉状态（如鼠标悬停、按下等）可以通过 VisualStateManager 进行管理，这实际上就是一种状态模式的应用。
组合模式：WPF 的控件树结构使得我们可以将多个控件组合成一个复合控件，这正是组合模式的体现。
单例模式：Application.Current 就是一个单例模式的实现。
原型模式：WPF 中资源的 Freezable 以及 Style 被多个控件使用，都体现出了对于原型实例的“克隆”。

总结

在软件开发中，设计模式为我们提供了高效、灵活的解决方案，帮助提升代码的可维护性和可扩展性。本文通过分析 WPF 中的几个经典设计模式，如观察者模式、桥接模式、装饰器模式、适配器模式和责任链模式，展示了这些模式如何在 WPF 框架中得以体现。

通过控件的事件机制、依赖属性、附加属性等机制，WPF 为开发者提供了丰富的设计模式支持，帮助开发者更好地组织和扩展应用程序。除此之外，WPF 还体现了状态模式、组合模式、单例模式等其他设计模式，为开发者提供了多种优秀的架构思想。

借助 ObservableCollections 获得更多具有通知功能的集合类型

Fri, 11 Jul 2025 00:00:00 +0000

如果大家在做基于 C# 的 WPF、Avalonia、Win UI 等开发，尤其是遵循 MVVM 模式时，遇到过下面的这些烦恼：

ObservableCollection 没有批量操作的功能（例如 AddRange）
缺少 ObservableDictionary、ObservableSet、ObservableQueue 等集合类型
难以实现诸如过滤、映射等功能

那么，ObservableCollections 这个 NuGet 包一定可以帮到你。没错，它就提供了一系列实用的具有通知功能的集合类型，使我们在 WPF、Avalonia、甚至 Unity 开发中都能够用得上。

安装

它的源代码链接在 GitHub 上。

如果想要安装它，我们只需要在 NuGet 包管理器中搜索 ObservableCollections，或者直接在项目中运行以下命令：

1

dotnet add package ObservableCollections

安装之后即可使用。注意它还有一个结尾包含 R3 的版本，是为它开发的 R3 库而准备的，通常我们不需要使用。这个 R3 库简单来说，就是一个更加高性能的 Rx.NET。

Info

说起它的开发者 Cysharp，那可真的可以说是如雷贯耳。比如他们开发的 Unitask，就是一个非常流行的适用于 Unity 的异步编程库；而他们开发的 ZLinq，最近也是非常有名。油管上的 Nick Chapsas 也曾经介绍过这个库。

支持批量操作的可观测集合

我们先来看一看它最简单的 ObservableList。它是一个具有通知功能的列表，并且支持批量操作。我们只需要实例化，然后就可以使用它了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


class MainViewModel
{
 private readonly ObservableList<string> _items = new();

 public MainViewModel()
 {
 // 添加单个元素
 _items.Add("Item 1");
 
 // 批量添加元素
 _items.AddRange(GetItems());
 }

 private IEnumerable<string> GetItems()
 {
 // 假定这个方法可以从某个数据源获取一些数据
 }
}

通过观察可以发现，这个集合类型提供了 CollectionChanged 事件，我们可以通过订阅它来监听集合的变化。但是先不要想当然地认为它和 ObservableCollection 一样。实际上，它的 CollectionChanged 事件并不是来自我们熟悉的那个 INotifyCollectionChanged 接口，而是这个库自带的一个接口。所以我们在上面的代码中，并没有直接将这个集合声明为 public 的属性，从而在 XAML 中绑定。

那么它为什么要这样做，让我们不能方便地使用呢？其实原因很简单：这个库不单单适用于 WPF，它还可以用于 Avalonia、Unity 等框架。为了兼容更多的框架，它就没有使用 INotifyCollectionChanged 接口，而是提供了一个更通用的接口。

但不必担心，它并没有止步于此，而是专门提供了方便我们在 WPF、Avalonia 等框架中使用的额外类型。简单来说，我们只需要调用它的下面这个方法，即可将它转为可以用于 XAML 绑定的集合对象：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


class MainViewModel
{
 private readonly ObservableList<string> _items = new();

 public INotifyCollectionChangedSynchronizedViewList<string> Items { get; }

 public MainViewModel()
 {
 Items = _items.ToNotifyCollectionChanged();
 }
}

这里的 INotifyCollectionChangedSynchronizedViewList 就继承了 INotifyCollectionChanged 接口，因此实现了该接口的对象就可以直接在 XAML 中绑定使用，例如：

1

<ListBox ItemsSource="{Binding Items}" />

接下来，我们只需要在后台操作 _items 集合，它的变化即可同步到 Items 集合中，从而在 UI 上自动更新。

创建集合视图

实际上，对于 ObservableList，我们除了可以使用 ToNotifyCollectionChanged 方法将其转换为可以用于 XAML 绑定的集合类型外，还可以使用 ToNotifyCollectionChangedSlim 方法，将它转为一个更加轻量级的集合类型。这个类型同样实现了 INotifyCollectionChanged 接口，但它的性能更高，适用于需要频繁更新的场景。代价是，它将不提供 AddRange 等批量操作方法。

这时候可能有同学就会问了：我用 ObservableList 而不是原生的 ObservableCollection，不就是为了它提供的批量操作方法吗？如果我不需要批量操作，直接用 ObservableCollection 不就行了吗？

这就引出了我们即将介绍的下一个功能，同时也是这个库相当重要的功能：View。这个 View 不是我们常说的 MVVM 中的视图，而是指对集合的视图。它可以让我们在不改变原始集合的情况下，对集合进行过滤、映射等操作。我们不需要关注视图的实现细节，只需要操作后台的集合，即可将更改同步到界面中。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


class MainViewModel
{
 private readonly ObservableList<string> _items = new();

 private readonly ISynchronizedView<string, string> _syncView;

 public INotifyCollectionChangedSynchronizedViewList<string> Items { get; }

 public MainViewModel()
 {
 _syncView = _items.CreateView(s => s.ToUpper());
 Items = _syncView.ToNotifyCollectionChanged();
 }

 public void ToggleFilter(bool useFilter)
 {
 if (useFilter)
 {
 _syncView.AttachFilter(s => s.StartsWith("A")); // 过滤以 "A" 开头的元素
 }
 else
 {
 _syncView.ResetFilter(); // 清除过滤器
 }
 }
}

Tip

如果我们只是想使用映射功能，那么使用 ToNotifyCollectionChanged 方法即可。它有一个重载，可以传入一个表示映射方式的 Func。另外，它还支持传入一个类似 Dispatcher 的参数，用于在 UI 线程上执行映射操作。至于为什么不是 WPF 中的 Dispatcher，而是一个它自己声明的类型，这也是为了兼容更多的框架。

在上面的代码中，我们创建了一个视图 _syncView。在创建时，我们就指定了一个映射函数，将集合中的每个元素转换为大写形式。然后在 ToggleFilter 方法中，我们可以通过 AttachFilter 及 ResetFilter 方法来添加或移除过滤器。就这样，我们轻松地实现了对集合的过滤和映射功能。

简单想象一下，这些功能在 WPF、Avalonia 等框架中原本实现起来会多么麻烦。对于映射，我们可以借助 DataTemplate 以及 ValueConverter 来实现；而对于过滤，我们可能需要使用 CollectionView 或者 ICollectionView 等。这些都需要我们编写大量的样板代码。

可观测的字典

WPF 中其实有一个 ObservableDictionary，但它并不是 public 的，只是标准库内部使用。或许我们可以使用一个 ObservableCollection<KeyValuePair<TKey, TValue>> 来模拟一个字典，但这效率并不高，因为字典的添加、删除、查找等操作都是 $O(1)$ 的，而 ObservableCollection 的这些操作都是 $O(n)$ 的。

至于 Avalonia，我们就比较幸运了，它直接提供了 AvaloniaList 和 AvaloniaDictionary，这两个集合类型，前者支持批量操作，后者则是一个可观测的字典。

下面我们用一个简单的例子来演示如何使用这个 ObservableDictionary。它的使用方式和 ObservableList 类似，我们只需要实例化它，然后就可以使用了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


class MainViewModel
{
 private readonly ObservableDictionary<string, string> _items = new();

 public INotifyCollectionChangedSynchronizedViewList<string> Items { get; }

 public MainViewModel()
 {
 Items = _items.ToNotifyCollectionChanged(pair => pair.Value);

 _items.Add("Key1", "Value1");
 }
}

可观测的队列

队列有时候也是一个我们用得上的集合类型。它的特点是先进先出（FIFO），适用于需要按照顺序处理元素的场景。比如我们希望存储一些实时的消息，并且希望仅展示最新的几十条，而当超过这个数量时，自动删除最旧的消息。这就要求我们需要能够高效地删除队列头部的元素。这对于传统的列表来说是比较麻烦的，因为这会引入 $O(n)$ 的时间复杂度。

ObservableCollections 库提供了一个 ObservableQueue<T>，不过我不打算详细介绍它，因为我们上面提到的需求有一个更加合适的集合类型，等下就会介绍到。但这里我们还是用一个简单的例子来演示它的用法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


class MainViewModel
{
 private readonly ObservableQueue<LogMessage> _logQueue = new();

 public INotifyCollectionChangedSynchronizedViewList<LogMessage> LogMessages { get; }

 public MainViewModel()
 {
 LogMessages = _logQueue.ToNotifyCollectionChanged();

 // 添加日志消息
 AddLogMessage("Application started");
 }

 public void AddLogMessage(string content)
 {
 var logMessage = new LogMessage(DateTime.Now.ToString("o"), content);

 // 如果队列超过 100 条，则删除最旧的消息
 if (_logQueue.Count >= 100)
 {
 _logQueue.Dequeue();
 }
 _logQueue.Enqueue(logMessage); 
 }
}

record LogMessage(string Timestamp, string Content);

Tip

事实上，如果我们的需求只是比如说保留最近的几十到一百条消息，那么直接使用传统的 ObservableCollection 也是完全可以接受的。虽然有点性能损失，但对于现在的 CPU 来说，这点复杂度完全是微不足道的。通过简单的 Benchmark，我们可以看到，List 可能只比 Queue 慢 50% 左右；甚至当数据量比较小（例如十几条）时，List 更是能在性能上超过 Queue。另外，List 的使用显然比 Queue 简单了不少。

可观测的环形缓冲区

下面我们要介绍的这个集合类型，正是这个包最推荐我们用来实现这个保留最近的一些消息的集合类型：RingBuffer。它是一个环形缓冲区，具有固定的大小。当添加新元素时，如果缓冲区已满，则会覆盖最旧的元素。这使得它非常适合用于存储最近的消息或数据。

这个包提供了两种环形缓冲区：ObservableRingBuffer 和 ObservableFixedSizeRingBuffer。前者支持动态调整大小，而后者则是一个固定大小的环形缓冲区。借助后者，我们前面的例子可以简化为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


class MainViewModel
{
 private readonly ObservableFixedSizeRingBuffer<LogMessage> _logBuffer = new(100);

 public INotifyCollectionChangedSynchronizedViewList<LogMessage> LogMessages { get; }

 public MainViewModel()
 {
 LogMessages = _logBuffer.ToNotifyCollectionChanged();

 // 添加日志消息
 AddLogMessage("Application started");
 }

 public void AddLogMessage(string content)
 {
 var logMessage = new LogMessage(DateTime.Now.ToString("o"), content);
 _logBuffer.Add(logMessage); // 添加新消息，自动覆盖最旧的消息
 }
}

就这样，我们轻松地实现了一个保留最近 100 条日志消息的集合。

线程安全

接下来这个部分相当重要，也是大家在使用这个包时需要尤其注意的，就是关于线程安全的问题。首先，这个包提供的每个集合都是线程安全的。它们内部会用一个线程锁，保证它的添加、删除等操作是线程安全的。但这并不意味着我们就可以高枕无忧了，因为虽然这些集合线程安全，但是从它们创建出的视图在同步它们的修改时，可能出现线程安全问题。那么，我们该怎么办呢？

首先，在使用 ToNotifyCollectionChanged 方法时，我们可以传入一个 Dispatcher 参数。前面提到，这个参数是该类库自己声明的类型。但是它提供了一个方便我们使用的单例：SynchronizationContextCollectionEventDispatcher.Current。借助它，我们就可以确保该方法创建出的视图在 UI 线程上执行修改操作，从而避免线程安全问题。

但是这还不够。实测发现，虽然背后的集合本身线程安全，但是它创建出来的视图在操作时仍面临着线程安全问题。尤其是数据不一致。比如我们在删除元素之后立刻添加了元素，那么这两次动作在同步到视图的过程中就可能会出现问题。对于这个问题，如果我们确实有在多线程上操作背后集合的需求，那么我们可以考虑让这些操作都发生在主线程上。以 WPF 为例，我们可以这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


class MainViewModel
{
 private readonly ObservableList<string> _items = new();

 public INotifyCollectionChangedSynchronizedViewList<string> Items { get; }

 public MainViewModel()
 {
 Items = _items.ToNotifyCollectionChanged(SynchronizationContextCollectionEventDispatcher.Current);
 }

 public void AddItem(string item)
 {
 // 确保在 UI 线程上执行添加操作
 Application.Current.Dispatcher.InvokeAsync(() => _items.Add(item));
 }

 public void RemoveItem(string item)
 {
 // 确保在 UI 线程上执行删除操作
 Application.Current.Dispatcher.InvokeAsync(() => _items.Remove(item));
 }
}

当然，在 ViewModel 中访问 Application.Current 可能并不是一个十分遵守 MVVM 模式的好习惯。因此在更加严谨的项目中，我们可以考虑将 Dispatcher 作为参数传入 ViewModel，或者使用依赖注入的方式来获取它。这样可以更好地遵循 MVVM 模式，同时也能确保在 UI 线程上执行操作。

总结

ObservableCollections 是一个非常实用的 NuGet 包，它提供了多种具有通知功能的集合类型，适用于 WPF、Avalonia、Win UI 等框架。它不仅支持批量操作，还提供了过滤、映射等功能，使得我们在开发中可以更加高效地处理集合数据。

在使用时，我们需要注意线程安全问题，尤其是在多线程环境下操作集合时。通过合理地使用 Dispatcher，我们可以确保集合的操作在 UI 线程上执行，从而避免数据不一致的问题。

WPF 中的 ContentControl 及 ContentPresenter 有何异同？

Wed, 05 Mar 2025 00:00:00 +0000

标题中提到的 ContentControl 和 ContentPresenter 都是 WPF 中较为常见的显示内容的控件，它们有各自的用途。但有的时候，开发者可能会搞不清楚它们之间的区别，导致选错了控件（却往往又因为效果实现了而忽视这一问题）。本文将简单介绍一下这两个控件的异同。

二者的共同点

首先，我们来看一下 ContentControl 和 ContentPresenter 之间的共同点：

都包含一个 Content 属性；
都可以用作一个将要展示内容的容器或占位符；
默认情况下通常都没有什么样式，完全透明且空白，看起来十分轻量。

因此，当用于展示一个控件或内容时，它们看起来都可以胜任。比如：

1
2
3


<ContentControl>
 <Button Content="Hello, World!" />
</ContentControl>

或者我们还可以在资源词典中声明一个控件：

1
2
3
4
5


<Window.Resources>
 <Button x:Key="MyButton" Content="Hello, World!" x:Shared="False" />
</Window.Resources>

<ContentControl Content="{StaticResource MyButton}" />

Info

这里我们使用了 x:Shared="False" 来确保每次使用这个资源时都会创建一个新的实例。否则，如果我们在多个地方使用这个资源，那么这些地方的控件都会指向同一个实例，导致一些问题（比如只有一个控件正确显示）。

当然了，我们还可以在代码后台去动态设置 Content 属性，这里我们就不演示了。

二者的区别

但正是因为它们有着这样的相同点，因此经常会有开发者误用了它们两个。那么，它们之间的区别又是什么呢？

它们的基类不同

ContentControl 是 Control 的子类，而 ContentPresenter 是 FrameworkElement 的子类。

首先我们来看 FrameworkElement。它提供了一些最基本的界面元素应该有的属性，比如宽高、样式、布局等。Control 是它的子类，额外添加了控件需要的边框、前背景色、字体等，还有一个相当重要的属性 Template，用于定义控件的外观。

然后，在这些的基础上，ContentControl 继承了 Control，并添加了一个 Content 属性，用于存放要展示的内容。不仅如此，因为它拥有模板（以及模板选择器等），因此它可以根据一些因素选择合适的模板从而去展示内容，并且非常适合在运行时动态改变内容。此外，它的 Content 不仅可以是一个具体的控件，还可以是一个数据模型等（通常还可以是绑定得到的）。

另一方面，ContentPresenter 并不拥有 Control 所提供的那些属性，可以说是一个相当轻量的界面元素。它的主要使用场景就是在模板中，用于展示模板的内容。比如我们可以在一个 Button 的模板中使用 ContentPresenter 来展示按钮的内容：

1
2
3
4
5


<ContentTemplate x:Key="MyButtonTemplate" TargetType="Button">
 <Border>
 <ContentPresenter />
 </Border>
</ContentTemplate>

不仅如此，因为它太适合用在这个场景了，所以通常我们根本不需要去操作它的 Content 属性，因为它会自动绑定到模板的 Content 属性上。也就是说，我们不需要写 Content="{TemplateBinding Content}" 这样的代码。

Info

其实 ContentPresenter 的作用就是在模板中用来展示 Content，所以 ContentControl 及其子控件自然也都用到了它。如果你在一个模板中，错误地将 ContentControl 用在了应该用 ContentPresenter 的地方，并且手写了 Content 属性的绑定，那么你仍然有可能看到正确的效果。只是它底层依旧是借助了 ContentPresenter。

它们的功能不同

因为上面的原因，所以即便它们看起来（甚至简单使用起来）并没有什么区别，但是它们被设计出来的目的及作用是完全不一样的。

ContentControl 一般来说有这么几种用途：

用于展示一个控件或内容（可以理解为容器或占位符）；
用作控件的基类，可以被继承，从而实现一些自定义的控件；
用于动态改变内容，比如在运行时改变 Content 属性；
搭配 DataTemplate 使用，用于根据数据模型展示不同的内容（尤其适用于导航页面）。

对于第 4 点，这里有一个简单的例子：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<ContentControl Content="{Binding CurrentPageViewModel}">
 <ContentControl.Resources>
 <DataTemplate DataType="{x:Type local:HomePage}">
 <local:HomePage />
 </DataTemplate>
 <DataTemplate DataType="{x:Type local:AboutPage}">
 <local:AboutPage />
 </DataTemplate>
 </ContentControl.Resources>
</ContentControl>

此时，虽然它的 Content 属性的值并不是一个控件，而是一个模型（Model），但是它会根据这个模型的类型自动选择合适的模板来展示内容。这样的话，只要我们给它提供视图模型（ViewModel），它就可以自动选择相应的视图（View）来展示，并且还会自动将 View 的 DataContext 设置为 Content 的值。

而 ContentPresenter 一般来说只有一种用途，那就是用在 ControlTemplate 中。类似的，还有一个 ItemsPresenter，用于在 ItemsControl （及其子控件，如 ListBox 等）的模板中展示子项。如果你在一个需要使用 ContentControl 的地方使用了 ContentPresenter，那么你不仅没有办法操作 Template 或提供 DataTemplate 来展示数据，而且还将没有办法操作一些最基本的 Control 的属性，比如前景色、背景色、字体等。

总结

深入了解 ContentControl 和 ContentPresenter 的区别，可能显得有些繁琐。其实大家基本上只需要记住，ContentPresenter 几乎只用于模板中，其余情况下都可以使用 ContentControl 即可。

让合适的控件做合适的事情，这样才有助于我们开发出更加清晰、稳健、易维护的代码。

WPF 中 ObjectDataProvider 的一些有趣用法

Fri, 07 Feb 2025 00:00:00 +0000

WPF 中的 ObjectDataProvider 是一个很有用的类。与常见的直接绑定到属性（包括控件的依赖属性、类的实例的属性、静态属性或字段等）不同的是，它可以通过调用构造函数的方式来创建对象，或调用对象的方法来获取数据，进而将其用作绑定的数据源。

这篇文章我们就来探讨一下它的一些实用而有趣的用法。

基本用法

创建对象

首先，我们来看一下最基本的用法：通过 ObjectDataProvider 来创建一个对象。比如我们有一个 Person 类：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


public class Person
{
 public string Name { get; set; }
 public int Age { get; set; }

 public Person(string name, int age)
 {
 Name = name;
 Age = age;
 }
}

如果 Person 提供了无参构造函数，那么我们可以用传统的方式直接实例化一个对象：

1
2
3


<Window.Resources>
 <local:Person x:Key="PersonObject" Name="Tom" Age="25" />
</Window.Resources>

但现在我们假设 Person 类只提供了有参构造函数，那么我们就无法直接实例化一个对象了。这时，我们可以通过 ObjectDataProvider 来实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


<Window ...>
 <Window.Resources>
 <ObjectDataProvider x:Key="PersonObject" ObjectType="{x:Type local:Person}">
 <ObjectDataProvider.ConstructorParameters>
 <sys:String>John</sys:String>
 <sys:Int32>25</sys:Int32>
 </ObjectDataProvider.ConstructorParameters>
 </ObjectDataProvider>
 </Window.Resources>
 <Grid>
 <TextBlock Text="{Binding Name, Source={StaticResource PersonObject}}" />
 <TextBlock Text="{Binding Age, Source={StaticResource PersonObject}}" />
 </Grid>
</Window>

这里我们通过 ObjectType 属性指定了 Person 类型，通过 ConstructorParameters 属性传入了构造函数的参数。这样我们就成功地创建了一个 Person 对象，并将其绑定到了两个 TextBlock 控件上。

调用方法

除了创建对象，ObjectDataProvider 还可以调用对象的方法。比如我们有一个 Calculator 类：

1
2
3
4
5
6
7


public class Calculator
{
 public int Add(int a, int b)
 {
 return a + b;
 }
}

我们可以通过如下方式调用 Add 方法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


<Window ...>
 <Window.Resources>
 <ObjectDataProvider x:Key="CalculatorObject" ObjectType="{x:Type local:Calculator}" MethodName="Add">
 <ObjectDataProvider.MethodParameters>
 <sys:Int32>10</sys:Int32>
 <sys:Int32>20</sys:Int32>
 </ObjectDataProvider.MethodParameters>
 </ObjectDataProvider>
 </Window.Resources>
 <Grid>
 <TextBlock Text="{Binding Source={StaticResource CalculatorObject}}" />
 </Grid>
</Window>

上面的方式会自动创建一个 Calculator 对象，并调用其 Add 方法，传入了两个参数。我们还可以将 Calculator 类及其成员声明为静态的，这样就可以避免创建对象了。

Info

如果 ObjectType 指定的类型不是静态的，那么即便我们要访问的属性或方法是静态的，ObjectDataProvider 也会自动创建一个对象。这一现象可以在运行时通过观察该资源的 ObjectInstance 属性来验证。

给定实例

除了指定 ObjectType 属性外，我们还可以通过 ObjectInstance 属性来指定一个实例。比如我们上面的 Calculator 类提供了单例模式的实现：

1
2
3
4
5
6


public class Calculator
{
 public static Calculator Instance { get; } = new();

 // ...
}

那么我们可以通过如下方式调用 Add 方法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


<Window ...>
 <Window.Resources>
 <ObjectDataProvider x:Key="CalculatorObject" ObjectInstance="{x:Static local:Calculator.Instance}" MethodName="Add">
 <ObjectDataProvider.MethodParameters>
 <sys:Int32>10</sys:Int32>
 <sys:Int32>20</sys:Int32>
 </ObjectDataProvider.MethodParameters>
 </ObjectDataProvider>
 </Window.Resources>
 <Grid>
 <TextBlock Text="{Binding Source={StaticResource CalculatorObject}}" />
 </Grid>
</Window>

当我们指定了 ObjectInstance 属性后，就不需要再指定 ObjectType 属性了。

工厂模式

还有一个经典用法是，我们可以结合工厂模式来在 XAML 中创建对象。比如我们有一个 PersonFactory 类：

1
2
3
4
5
6
7


public class PersonFactory
{
 public Person CreatePerson(string name, int age)
 {
 return new Person(name, age);
 }
}

我们可以通过如下方式创建一个 Person 对象：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<Window ...>
 <Window.Resources>
 <ObjectDataProvider x:Key="PersonFactory" ObjectType="{x:Type local:PersonFactory}" MethodName="CreatePerson">
 <ObjectDataProvider.MethodParameters>
 <sys:String>John</sys:String>
 <sys:Int32>25</sys:Int32>
 </ObjectDataProvider.MethodParameters>
 </ObjectDataProvider>
 </Window.Resources>
</Window>

这样便为 XAML 注入了更多的活力与灵活性。

经典用法

绑定枚举类型到下拉选单

相信所有和 ComboBox 控件打过交道的开发者都知道，如果我们希望将一个枚举类型的值绑定到 ComboBox 控件上，我们可以通过 ObjectDataProvider 来实现。

比如我们有一个 Fruit 枚举类型：

1
2
3
4
5
6
7


public enum Fruit
{
 Apple,
 Banana,
 Orange,
 Pear
}

我们可以通过如下方式将其绑定到 ComboBox 控件上：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


<Window ...>
 <Window.Resources>
 <ObjectDataProvider x:Key="FruitEnumValues" MethodName="GetValues" ObjectType="{x:Type sys:Enum}">
 <ObjectDataProvider.MethodParameters>
 <x:Type TypeName="local:Fruit"/>
 </ObjectDataProvider.MethodParameters>
 </ObjectDataProvider>
 </Window.Resources>
 <Grid>
 <ComboBox ItemsSource="{Binding Source={StaticResource FruitEnumValues}}" />
 </Grid>
</Window>

这里其实就体现了对于类型方法的调用。首先，我们知道在 C# 中，可以通过这样的方式来获取枚举类型的所有值：

1

var values = Enum.GetValues(typeof(Fruit));

也就是我们调用了 Enum 类型的 GetValues 静态方法，并传入了 Fruit 类型（Type），从而获取所有的枚举值。而在 XAML 中，我们就是借助 ObjectDataProvider 来实现了相同的操作。我们通过 ObjectType 属性指定了 Enum 类型，通过 MethodName 属性指定了 GetValues 方法，再通过 MethodParameters 属性传入了 Fruit 类型。

为下拉选单提供整数数据源

借鉴上面的思路，我们很容易产生更多的想法：既然它可以调用任何类型的方法，那么 LINQ 的 Enumerable 上面的一些静态方法岂不也能为我们所用了？

那么我们就赶快来试一试吧。我们假如我们想给一个 ComboBox 添加几个连续的数字作为它的选项（比如 1~5），在代码后台我们会这样调用：

1

var numbers = Enumerable.Range(1, 5);

那么在 XAML 中，我们可以这样实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


<Window xmlns:linq="clr-namespace:System.Linq;assembly=netstandard">
 <Window.Resources>
 <ObjectDataProvider x:Key="Numbers" MethodName="Range" ObjectType="{x:Type linq:Enumerable}">
 <ObjectDataProvider.MethodParameters>
 <sys:Int32>1</sys:Int32>
 <sys:Int32>5</sys:Int32>
 </ObjectDataProvider.MethodParameters>
 </ObjectDataProvider>
 </Window.Resources>
 <Grid>
 <ComboBox ItemsSource="{Binding Source={StaticResource Numbers}}" />
 </Grid>
</Window>

是不是很有意思呢？

总结

ObjectDataProvider 是一个非常有用的类，它可以帮助我们在 XAML 中实现更多的功能。通过调用构造函数或对象的方法，我们可以实现更多的数据绑定操作。在实际开发中，我们可以根据具体的需求，灵活地使用 ObjectDataProvider，从而提高开发效率。

不过，好用归好用，它或许并不总是最优解。如果我们可以借助 ViewModel 中的成员，或 MarkupExtension 等方式来实现，那么我们一般就可以不考虑使用 ObjectDataProvider 了。毕竟，ObjectDataProvider 声明起来还是显得有些繁琐，而且因为借助反射，我们在编译时也可能无法发现一些潜在的问题。

如何在 WPF 中高效布局多行多列的控件

Thu, 26 Dec 2024 00:00:00 +0000

这次我们来探讨一个 WPF 中的简单而又不简单的布局问题：如何实现下图中的效果？

为什么说这个问题简单而又不简单呢？是因为单纯只是实现这个效果的话，我们完全可以使用 Grid 控件来实现。~~甚至如果完全不在乎优雅的话，我们还可以用 Canvas 来实现~~（当然这几乎在任何情况下都是不推荐的）。但是，实际这样干过的开发者相信都很清楚，使用 Grid 的实现方式几乎可以说是毫无灵活性的。很快就会被后续的界面微调的需求整得焦头烂额。

那么我们今天就来看一看，这样的需求通常有哪些做法吧。希望这篇文章中提到的某些方式能够帮助到你。

最传统的方式：Grid

在介绍后面的更好的方式之前，我们有必要先来看一看最传统的方式：使用 Grid 控件。这样才能更好地分析这种方式的局限性，以及思考改进的方向。

这样的方式相信所有具备基本 WPF 基础的开发者都相当熟悉：

在 XAML 中定义一个 Grid 控件
在 Grid 中定义多个 RowDefinition 和 ColumnDefinition
在 Grid 中定义多个控件，并通过 Grid.Row 和 Grid.Column 来指定控件的位置
（可选）通过 Grid.RowSpan 和 Grid.ColumnSpan 来指定控件的跨行和跨列

好，然后我们就开始写 XAML 吧：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


<Grid>
 <Grid.RowDefinitions>
 <RowDefinition Height="Auto" />
 <RowDefinition Height="Auto" />
 <RowDefinition Height="Auto" />
 <RowDefinition Height="Auto" />
 </Grid.RowDefinitions>
 <Grid.ColumnDefinitions>
 <ColumnDefinition Width="Auto" />
 <ColumnDefinition Width="Auto" />
 </Grid.ColumnDefinitions>

 <Label Grid.Row="0" Grid.Column="0" Content="1" />
 <TextBox Grid.Row="0" Grid.Column="1" />
 <Label Grid.Row="1" Grid.Column="0" Content="2" />
 <TextBox Grid.Row="1" Grid.Column="1" />
 <!-- ... -->
</Grid>

好的，马上痛苦面具就戴上了：为每个控件写 Grid.Row 和 Grid.Column，简直就是顶级折磨。如果你搞了十几行，结果被告知需要删掉前面某一行，或者在前面添加一行，那就更是欲哭无泪了。

Tip

可能会有聪明的同学想到一些简化这一步骤的方式，比如使用 Style 来统一指定上面的 TextBox 控件的 Grid.Column，并省略 Label 的 Grid.Column="0"。但这样依旧存在相当多的局限性，毕竟它最怕的就是例外情况了。

所以，我们显然是不能满足于使用这样的方式的。那究竟有什么更好的方式呢？

外层使用 UniformGrid

说起“自动化布局”，相信很多人在使用 Grid 时都垂涎过 UniformGrid 的功能，因为它可以让所有子控件依次填充到每个单元格中。所以，我们或许可以借助它的这一效果。比如我们想要一个两列的网格，可以：

1
2
3
4
5
6


<UniformGrid Columns="2">
 <Label Content="1" />
 <TextBox />
 <Label Content="2" />
 <TextBox />
 <!-- ... -->

但这样的局限性在于，所有子控件的大小（或者它们所处的单元格）都是完全等大的。这可能会失去灵活性，并且看起来有些呆板。那么我们还可以部分借助 UniformGrid 的功能，比如下面这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


<UniformGrid Columns="1">
 <UniformGrid.Resources>
 <Style TargetType="StackPanel">
 <Setter Property="Orientation" Value="Horizontal" />
 </Style>
 <Style TargetType="Label">
 <Setter Property="Width" Value="50" />
 </Style>
 </UniformGrid.Resources>
 <StackPanel>
 <Label Content="1" />
 <TextBox />
 </StackPanel>
 <StackPanel>
 <Label Content="2" />
 <TextBox />
 </StackPanel>
 <!-- ... -->
</UniformGrid>

这里我们将每一行的内容放在了一个 StackPanel 中，从而让 Label 和 TextBox 出现在同一行（或者说 UniformGrid 的同一个单元格中）。这样我们就不需要再为每个控件指定 Grid.Row 和 Grid.Column 了。

为了更加简化代码，我们还声明了两个 Style，分别用于设置 StackPanel 的 Orientation 和 Label 的 Width。这样我们就可以在 StackPanel 中直接放置 Label 和 TextBox，而不需要再为 Label 设置宽度了。

但是这样做有一个明显的局限性：行高是一致的。如果我们需要不同行的高度不一致，那么这种方式就无法满足需求了。

外层使用 StackPanel

为了突破上一个方式的局限性，我们可以考虑使用 StackPanel 来替代 UniformGrid。这样我们就可以为每一行的 StackPanel 设置不同的高度了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


<StackPanel Orientation="Vertical">
 <StackPanel.Resources>
 <!-- Styles -->
 </StackPanel.Resources>
 <StackPanel Height="40">
 <Label Content="1" />
 <TextBox />
 </StackPanel>
 <StackPanel Height="50">
 <Label Content="2" />
 <TextBox />
 </StackPanel>
 <!-- ... -->
</StackPanel>

但很快，我们又会被别的问题所折磨：如何高效地设置行间距？

而且可能还有另外一个小折磨：因为内外都使用了 StackPanel，所以写的 Style 可能会被它们共同使用。

Info

针对这一问题，可能有同学会将内部的 StackPanel 替换为 WrapPanel，但这样并不是一个好主意，因为 WrapPanel 会让每一行的控件都尽可能地靠左对齐，并且在宽度不够时会自动换行！或许现在看着还好，但调整了窗口或父控件的尺寸，甚至修改了分辨率及缩放后，都有可能让你的界面变得一团糟。

此时，我们可以请个“外援”。其实在 Win UI 3、Avalonia UI 等框架中，StackPanel 天生就比 WPF 多了一个属性：Spacing。这个属性可以让我们很方便地设置行间距。但是在 WPF 中，我们就没有这么幸运了。不过，我们可以借助自定义控件来实现这一功能。

代码也不用我们自己写，网上可以找到一些开源实现。比如这里我贴两个供大家参考：

假如我们搬运到了 local 命名空间下，那么我们就可以这样使用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


<local:StackPanel Spacing="10">
 <local:StackPanel.Resources>
 <Style TargetType="StackPanel">
 <Setter Property="Orientation" Value="Horizontal" />
 </Style>
 </local:StackPanel.Resources>
 <StackPanel>
 <Label Content="1" />
 <TextBox />
 </StackPanel>
 <StackPanel>
 <Label Content="2" />
 <TextBox />
 </StackPanel>
 <!-- ... -->
</local:StackPanel>

这样看起来就方便多了。此外，我们还有一些小技巧，来进一步提高布局的效率：

为 Label 设置一个固定的宽度，这样可以让所有的 Label 对齐
为 Label 设置 VerticalAlignment 或 VerticalContentAlignment 为 Center，这样可以让 Label 和 TextBox 垂直居中对齐
为 TextBox 等控件（还比如 CheckBox、ComboBox 等）设置固定的宽度，这样可以让所有的 TextBox 对齐

使用更高级的 Grid

上面的方式其实已经相当灵活了，尤其是对于可能需要增删、调换顺序之类的情形。但是可能仍然会觉得不够爽，因为里面多出了一层 StackPanel，这写起来就还是会觉得不太爽。

所以，有没有办法让 Grid 更加智能一点，比如可以像是 WrapPanel 或者 UniformGrid 那样，自动填充控件呢？

答案当然是有的。这里给大家推荐一个 NuGet 包：WpfAutoGrid。这个 AutoGrid 就正是我们梦寐以求的控件。

Info

NuGet 上有好多个叫这个名字的包。这里我贴一个自己试过的：WpfAutoGrid.Core

它的使用也非常简单：

1
2
3
4
5
6
7


<local:AutoGrid Columns="100,150" RowCount="8" RowHeight="30">
 <Label Content="1" />
 <TextBox />
 <Label Content="2" />
 <TextBox />
 <!-- ... -->
</local:AutoGrid>

这样我们连内部的 StackPanel 都不需要了，直接将 Label 和 TextBox 放在 AutoGrid 中即可。此外，它提供了很多实用的属性，比如上面实用的 Columns、RowCount、RowHeight，还有 ColumnSpacing、RowSpacing 等。不仅如此，AutoGrid 还能正确响应子控件 ColumnSpan 等属性，可以让我们更加灵活地布局控件。

除此之外，这里我再贴一个我自己写的 GridAssist。它是一个附加属性，可以直接用于原生的 Grid 控件。使用这个附加属性，就能够自动为子控件添加 Grid.Row 和 Grid.Column 属性。

BYJRK/GridAssist

使用方式也非常简单：

1
2
3
4
5
6
7


<Grid local:GridAssist.AutoRowColumn="_,2">
 <Label Content="1" />
 <TextBox />
 <Label Content="2" />
 <TextBox />
 <!-- ... -->
</Grid>

这个附加属性的 AutoRowColumn 填写的 _,2 意思是，行数自动增加，列数固定为 2（还可以写 _,2,Auto，从而将列宽设置为 Auto）。这样我们就不需要为每个控件指定 Grid.Row 和 Grid.Column 了。然后，我们只需要将子控件按照从上到下，从左到右的顺序放置即可，不需要再引入一层 StackPanel 了。此外，它也是可以正确响应 Grid.ColumnSpan 的。

总结

在 WPF 中，布局是一个非常重要的问题。而对于多行多列的控件布局，我们可以使用 Grid、UniformGrid、StackPanel、AutoGrid 等控件或者附加属性来实现。每一种方式都有它的优势和局限性，我们可以根据实际情况来选择最适合的方式。

另外，对于上面提到的几种自定义控件或附加属性，我们完全可以直接将代码复制到自己的项目中，然后根据实际需求进行修改。这样可以更好地适应自己的项目，也可以更好地理解这些控件或属性的实现原理，还可以省去引入第三方库的麻烦。

WPF 值转换器（ValueConverter）的一些实用技巧

Wed, 18 Dec 2024 00:00:00 +0000

本篇文章对应的教学视频链接：WPF中值转换器（ValueConverter）的一些实用技巧

在 WPF 中，值转换器（ValueConverter）是一个非常重要的概念。它可以帮助我们在绑定数据时，将数据转换成我们需要的格式。在这篇文章中，我们将介绍一些值转换器的实用技巧。

使用 WPF 内置的值转换器

WPF 内置了几个常用的值转换器，我们可以直接使用。例如，我们可以使用 BooleanToVisibilityConverter 将布尔值转换成 Visibility 枚举值。

1
2
3
4
5
6
7
8


<Window.Resources>
 <BooleanToVisibilityConverter x:Key="BooleanToVisibilityConverter"/>
</Window.Resources>

<StackPanel>
 <CheckBox x:Name="checkBox" Content="Show Text" IsChecked="True"/>
 <TextBlock Text="Hello, World!" Visibility="{Binding ElementName=checkBox, Path=IsChecked, Converter={StaticResource BooleanToVisibilityConverter}}"/>
</StackPanel>

遗憾的是，WPF 内置的值转换器并不是很多，基本上我们能直接用上的就是上面提到的这个 BooleanToVisibilityConverter。其他虽然有一些照理说用得上的值转换器，但它们很多都是 internal 的，我们无法直接使用。即便如此，通过阅读它们的源代码，我们仍然可以学习一下它们的实现方式。比如：

将值转换器声明为单例

使用值转换器有些是否会让人觉得繁琐，因为通常这意味着我们需要在某个控件的 Resources 中声明一个值转换器，并在需要的地方通过 StaticResource 来引用它。但实际上，我们可以将值转换器声明为单例，这样就可以在任何地方直接使用它。比如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


public class BooleanToVisibilityConverter : IValueConverter
{
 // 单例模式
 public static BooleanToVisibilityConverter Instance { get; } = new();

 public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
 {
 // ...
 }

 public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
 {
 // ...
 }
}

然后我们就可以在 XAML 中借助 x:Static 来直接使用这个单例：

1
2
3
4


<StackPanel>
 <CheckBox x:Name="checkBox" Content="Show Text" IsChecked="True"/>
 <TextBlock Text="Hello, World!" Visibility="{Binding ElementName=checkBox, Path=IsChecked, Converter={x:Static local:BooleanToVisibilityConverter.Instance}}"/>
</StackPanel>

Warning

这样确实可以一定程度上简化我们的代码，但也要注意，这样做可能会导致值转换器的状态被共享，从而引发一些问题。所以在使用这种方式时，一定要确保值转换器是无状态的。

将值转换器声明在 App.xaml 中

如果我们有一些相当通用且无状态的值转换器，就比如 BooleanToVisibilityConverter、BoolReverseConverter、NotNullConverter 等，我们可以将它们声明在 App.xaml 中，这样就可以在整个应用程序中直接使用这些值转换器，而不需要在每个用到它们的 Window、UserControl 等地方都进行声明。

1
2
3
4
5
6
7


<Application ...>
 <Application.Resources>
 <BooleanToVisibilityConverter x:Key="BooleanToVisibilityConverter"/>
 <BoolReverseConverter x:Key="BoolReverseConverter"/>
 <NotNullConverter x:Key="NotNullConverter"/>
 </Application.Resources>
</Application>

如果觉得这样的方式会“污染”App.xaml，我们也可以新建一个 ResourceDictionary，并将这些值转换器声明在这个 ResourceDictionary 中，然后在 App.xaml 中引用这个 ResourceDictionary。例如，我们可以新建一个 CommonConverters.xaml：

1
2
3
4
5


<ResourceDictionary ...>
 <BooleanToVisibilityConverter x:Key="BooleanToVisibilityConverter"/>
 <BoolReverseConverter x:Key="BoolReverseConverter"/>
 <NotNullConverter x:Key="NotNullConverter"/>
</ResourceDictionary>

然后在 App.xaml 中引用这个 ResourceDictionary：

1
2
3
4
5
6
7
8
9


<Application ...>
 <Application.Resources>
 <ResourceDictionary>
 <ResourceDictionary.MergedDictionaries>
 <ResourceDictionary Source="CommonConverters.xaml"/>
 </ResourceDictionary.MergedDictionaries>
 </ResourceDictionary>
 </Application.Resources>
</Application>

使用 `MarkupExtension` 简化值转换器的使用

Markup 语法也就是我们经常在 XAML 中看到的“花括号”语法，例如：

{Binding ...}
{StaticResource ...}
{x:Static ...}

只要我们让值转换器继承 MarkupExtension，我们就可以在 XAML 中直接使用 Markup 语法来引用这个值转换器。比如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


public class BooleanToVisibilityConverter : MarkupExtension, IValueConverter
{
 public bool IsReversed { get; set; }

 public bool UseHidden { get; set; }

 public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
 {
 if (value is bool b)
 {
 b = IsReversed ? !b : b;
 return b ? Visibility.Visible : (UseHidden ? Visibility.Hidden : Visibility.Collapsed);
 }
 }

 public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
 {
 if (value is Visibility visibility)
 {
 return visibility == Visibility.Visible;
 }
 }

 public override object ProvideValue(IServiceProvider serviceProvider)
 {
 return this;
 }
}

上面是一个“高级版”的 BooleanToVisibilityConverter，它支持 IsReversed 和 UseHidden 两个属性，也就为这一值转换器提供了定制性。我们可以在 XAML 中这样使用它：

1
2
3
4


<StackPanel>
 <CheckBox x:Name="checkBox" Content="Show Text" IsChecked="True"/>
 <TextBlock Text="Hello, World!" Visibility="{Binding ElementName=checkBox, Path=IsChecked, Converter={local:BooleanToVisibilityConverter IsReversed=True, UseHidden=True}}"/>
</StackPanel>

这一技巧尤其适用于某个定制功能强大，且使用频率较高的值转换器。但也要注意，这样声明就会导致值转换器每次都会实例化一个新的出来。如果一个值转换器是无状态的，那么我们最好将其声明为单例，或者将其声明在 App.xaml 中，从而避免重复实例化。

如果还觉得不过瘾，我们可以为值转换器写一个抽象基类，从而进一步简化值转换器的实现。比如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


public abstract class BaseValueConverter : MarkupExtension, IValueConverter
{
 public override object ProvideValue(IServiceProvider serviceProvider)
 {
 return this;
 }

 public abstract object Convert(object value, Type targetType, object parameter, CultureInfo culture);

 public virtual object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
 {
 return Binding.DoNothing;
 }
}

另外还有一种版本，就是希望基类还顺便提供单例模式，那么我们可以这样：

1
2
3
4
5
6
7


public abstract class BaseValueConverter<T> : MarkupExtension, IValueConverter
 where T : class, new()
{
 public static T Instance { get; } = new();

 // ...
}

然后我们就可以使用它了。比如说我们希望实现一个单向的值转换器，将字符串转换成大写，可以这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


public class StringToUpperConverter : BaseValueConverter<StringToUpperConverter>
{
 public override object Convert(object value, Type targetType, object parameter, CultureInfo culture)
 {
 if (value is string s)
 {
 return s.ToUpper();
 }

 return Binding.DoNothing;
 }
}

是不是瞬间变得简单了很多呢？

返回 DoNothing 与 UnsetValue

在 WPF 中，有两个特殊的返回类型，分别是 Binding.DoNothing 和 DependencyProperty.UnsetValue。在某些情况下，让值转换器的方法返回这两个值是非常有用的。

这两个都表示“不做任何事情”，但它们的使用场景是不同的。具体来说，Binding.DoNothing 单纯意味着“不做任何事情”，不去通知任何绑定源或目标，也不会更新界面；而 DependencyProperty.UnsetValue 则暗示绑定是失败的，或者值是无效的。此时，它会触发 Binding 的 FallbackValue，也就是俗称的“缺省值”。

比如我们有一个可以让用户输入文件路径的文本框，并且我们会让另一个 TextBlock 展示这个文件的名称。但是如果用户输入的路径是无效的，我们就不希望展示这个文件的名称，而是展示一个缺省值，这时我们就可以使用 DependencyProperty.UnsetValue：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


public class FilePathToFileNameConverter : IValueConverter
{
 public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
 {
 if (value is string path &&n File.Exists(path))
 {
 return Path.GetFileName(path);
 }
 return DependencyProperty.UnsetValue;
 }
}

然后我们可以在 XAML 中这样使用：

1
2
3
4


<StackPanel>
 <TextBox x:Name="textBox" Text="C:\Users\Public\Documents\file.txt"/>
 <TextBlock Text="{Binding ElementName=textBox, Path=Text, Converter={local:FilePathToFileNameConverter}, FallbackValue='Invalid File Path'}"/>
</StackPanel>

这样，当用户输入的文件路径无效时，TextBlock 就会展示“Invalid File Path”。

类似地，如果我们希望用户在输入无效的文件路径时，不做任何事情（比如保留上次有效的文件名城），我们就可以返回 Binding.DoNothing。然后就可以实现相应的效果了。

这两个特殊的返回值看似不起眼，但是如果上述功能让我们在 ViewModel 中去实现，就会变得非常繁琐。所以在这种情况下，值转换器就显得非常有用了。

借助 CultureInfo 实现多语言支持

值转换器中的两个方法都有一个 CultureInfo 类型的参数，我们可以利用这个参数来实现多语言支持。比如我们有一个值转换器，将数字转换成各国语言的数字。此时我们就可以在值转换器中根据 CultureInfo 所包含的地区码来选择合适的语言。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


public class NumberToLocalizedNumberConverter : IValueConverter
{
 public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
 {
 if (value is int number)
 {
 switch (culture.TwoLetterISOLanguageName)
 {
 case "zh":
 return number switch
 {
 0 => "零",
 1 => "一",
 2 => "二",
 3 => "三",
 4 => "四",
 5 => "五"
 };
 case "en":
 return number switch
 {
 0 => "Zero",
 1 => "One",
 2 => "Two",
 3 => "Three",
 4 => "Four",
 5 => "Five"
 };
 default:
 return number.ToString();
 }
 }

 return Binding.DoNothing;
 }
}

然后我们可以在 XAML 中这样使用：

1
2
3


<StackPanel>
 <TextBlock Text="{Binding Number, Converter={local:NumberToLocalizedNumberConverter}, ConverterCulture=zh-CN}"/>
</StackPanel>

或者我们也可以在程序中动态地设置 CultureInfo：

1
2
3
4


var culture = new CultureInfo("zh-CN");

Thread.CurrentThread.CurrentCulture = culture;
Thread.CurrentThread.CurrentUICulture = culture;

但是这样还不够，因为值转换器的这一入参是从控件的 Language 属性中继承而来的。所以我们还需要修改全局的 Language 属性。例如，我们想在一个 UserControl 中使用中文，可以这样：

1
2
3
4
5
6


<UserControl Language="zh-CN">
 <!-- 也可以这样写 -->
 <UserControl.Language>
 <XmlLanguage>zh-CN</XmlLanguage>
 </UserControl.Language>
</UserControl>

或者，我们还可以用 OverrideMetadata 的方式来修改全局的 Language 属性：

1
2
3
4
5
6
7


FrameworkElement.LanguageProperty
 .OverrideMetadata(
 typeof(FrameworkElement),
 new FrameworkPropertyMetadata(
 XmlLanguage.GetLanguage(CultureInfo.CurrentCulture.IetfLanguageTag)
 )
 );

这样就可以让值转换器获取到当前的 CultureInfo，从而实现多语言支持。

仿照 Avalonia UI 实现一个 FuncValueConverter

Avalonia UI 中有一个有趣的 FuncValueConverter，它允许我们直接在代码后台简单地声明一个值转换器，而不需要额外写一个类。它地源代码可以在 GitHub 上看到。我们可以仿照这个实现一个类似的值转换器。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


public sealed class FuncValueConverter<TIn, TOut> : IValueConverter
{
 private readonly Func<TIn, TOut> _convert;

 public FuncValueConverter(Func<TIn, TOut> convert)
 {
 _convert = convert;
 }

 public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
 {
 if (value is TIn t)
 {
 return _convert(t);
 }

 return Binding.DoNothing;
 }

 public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
 {
 return Binding.DoNothing;
 }
}

对于 Convert 方法的实现，这里还有一种更好的方式。我们都知道，在 XAML 书写的很多资源，WPF 都会在底层帮我们进行合适的类型转换。比如我们将 "1" 字符串赋值给一个 int 类型的属性，WPF 会自动将其转换成 1；我们将 "Visible" 字符串赋值给一个 Visibility 枚举类型的属性，WPF 也会进行相应的转换。如果我们不提供这个功能，那么我们写的这个 FuncValueConverter 就会变得不够灵活。因此，我们可以借助 .NET 原生的 TypeDescriptor 类来实现这个功能。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
 if (value is not TIn t)
 {
 if (value is null)
 {
 return default(TOut);
 }

 if (TypeDescriptor.GetConverter(typeof(TIn)).CanConvertFrom(value.GetType()))
 {
 t = (TIn)TypeDescriptor.GetConverter(typeof(TIn)).ConvertFrom(value);
 }
 else
 {
 return Binding.DoNothing;
 }
 }

 return _convert(t);
}

这样我们就可以声明并使用了。我们需要将它声明为静态属性：

1
2
3
4


public class MainViewModel : ViewModelBase
{
 public static FuncValueConverter<string, int> StringToIntConverter { get; } = new(s => int.Parse(s));
}

然后我们就可以在 XAML 中这样使用：

1
2
3
4


<StackPanel>
 <TextBox x:Name="textBox" Text="123"/>
 <TextBlock Text="{Binding ElementName=textBox, Path=Text, Converter={x:Static local:MainViewModel.StringToIntConverter}}"/>
</StackPanel>

这样，我们就能够轻易地在代码后台声明一个值转换器了。

其他第三方库

除了上面提到的这些方法，我们还可以使用一些第三方库来简化值转换器及绑定的使用。比如：

这些库有的提供了丰富的内置值转换器，包括组合多种值转换器的功能（例如先将字符串根据 IsNullOrEmpty 转为 bool 类型，再转为 Visibility 类型），有的提供了更加强大的绑定功能，例如可以调用函数，进行数学运算等等。大家有兴趣的话可以去了解一下。

总结

值转换器是 WPF 中非常重要的一个概念，它可以帮助我们将数据转换成我们需要的格式。在这篇文章中，我们介绍了一些值转换器的实用技巧。希望这些技巧能够帮助大家更好地使用值转换器。

只有充分发挥 WPF 中各个功能的优势，我们才能更好地提高我们的开发效率，实现更加复杂的功能。希望大家能够在实际的开发中多多尝试，多多实践。

WPF 中的 Name 与 x:Name 究竟是什么区别？

Thu, 10 Oct 2024 00:00:00 +0000

在 WPF 开发中，我们可以给控件添加 Name 或 x:Name 属性。这样做的目的通常是希望在代码后台能够访问这个控件，或者我们在写 Binding 表达式时，希望使用 ElementName 的方式绑定某个控件。那么这二者究竟是什么区别呢？本文就来简单探讨一下。

本质不同，但却又几乎相同

别的暂且不谈，我们只关注 XML 文档的命名空间，不难发现 Name 和 x:Name 的区别在于前者没有命名空间，而后者有一个 x 命名空间。具体来说，通常我们的一个 XAML 文件的根元素是这样的：

1
2
3
4
5
6


<Window x:Class="WpfApp1.MainWindow"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Title="MainWindow" Height="450" Width="800">
 <!-- 省略其他内容 -->
</Window>

其中，xmlns 是默认的命名空间，而 xmlns:x 是 x 命名空间。所以，x:Name 和 Name 分别出自哪个命名空间，就不言而喻了。

但是，虽然它们两个出身不同，但在 WPF 中，它们的作用几乎是一样的。具体来说，Name 是 FrameworkElement 类（以及 FrameworkContentElement 类，下略）的一个依赖属性，形如（为便于阅读，代码略有删改）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


[CommonDependencyProperty]
public static readonly DependencyProperty NameProperty =
 DependencyProperty.Register(
 "Name",
 typeof(string),
 typeof(FrameworkElement),
 new FrameworkPropertyMetadata(/* ... */);

[Localizability(LocalizationCategory.NeverLocalize)]
[MergableProperty(false)]
[DesignerSerializationOptions(DesignerSerializationOptions.SerializeAsAttribute)]
public string Name
{
 get { return (string) GetValue(NameProperty); }
 set { SetValue(NameProperty, value); }
}

而进一步观察 FrameworkElement 类的声明，我们可以发现：

1
2
3
4
5
6
7
8


namespace System.Windows
{
 [RuntimeNamePropertyAttribute("Name")]
 public partial class FrameworkElement
 {
 // ...
 }
}

这里的 RuntimeNamePropertyAttribute 是一个特性，它告诉 WPF 运行时，FrameworkElement 类的 Name 属性将会被转为 x:Name 属性。所以，Name 和 x:Name 在 WPF 中几乎是一样的。

至于为什么要这样设计，我并没有找到官方的答案。唯一合理的猜测，就是想给开发者一个较为方便的方式去给控件命名。毕竟，Name 比 x:Name 看起来更简洁，更加直观（毕竟这看起来就是属于控件自己的名字一样），而且还不需要使用命名空间。

x:Name 本质上意味着什么？

那么，既然二者并没有多少区别，我们现在就来看一看 x:Name 到底意味着什么。在 XAML 中，当我们给控件添加 x:Name 属性时，实际上是在告诉 XAML 解析器，这个控件的名字是什么。并且相信大家都知道，拥有了名字的控件，它就会变成类的字段，我们可以在代码后台通过这个名字来访问它。

具体来说，以 Window 为例，我们会发现后台代码是一个分部类。在我们看不到的地方，XAML 解析器会生成一个类。这个类中就有我们最熟悉的在构造函数中调用的 InitializeComponent 方法，以及我们在 XAML 中添加了 Name 的控件所对应的字段。例如，我们在 XAML 中这样写：

1
2
3
4
5
6
7


<Window x:Class="WpfApp1.MainWindow"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Title="MainWindow" Height="450" Width="800">
 <Button x:Name="button1" Content="Click Me" />
 <Button x:Name="button2" x:FieldModifier="private" Content="Click Me" />
</Window>

那么，我们就能在后台生成的代码（文件名类似 MainWindow.g.i.cs）中找到这样的内容（我们可以在后台随便一个地方访问这个字段，然后用 IDE 的跳转到定义的方式找到后台生成的代码）：

1
2
3
4
5


public partial class MainWindow : // ...
{
 internal System.Windows.Controls.Button button1;
 private System.Windows.Controls.Button button2;
}

此外，如果 XAML 中的一个控件拥有了 Name，我们还可以实现一些别的事情。包括但不限于：

在 Binding 表达式中使用 ElementName 来绑定这个控件；
在 Storyboard 中使用 TargetName 来指定这个控件；
在后台代码中使用 FindName 方法来查找这个控件。

总结

本文简单介绍了 WPF 中的 Name 和 x:Name 属性。虽然它们在本质上有一些区别，但在 WPF 中，它们的作用几乎是一样的。

围绕着 Name 这个概念，其实能聊的还有很多。比如：

NameScope 的概念；
当持有 Name 的控件在 ControlTemplate 或 DataTemplate 中时会怎样；
与之相关的其他来自 x 命名空间的属性，比如 x:FieldModifier、x:Reference 等。

这些内容，我们会在以后的文章中继续探讨。

参考

WPF 设计时特性的实用技巧

Sat, 07 Sep 2024 00:00:00 +0000

本文有对应的视频教程：哔哩哔哩

相信无数 WPF 开发者在开发过程中，都会遭受过很多这样或那样的痛苦，比如：

在设计 TextBlock 控件时，因为无法预览字体、字号、颜色等属性，导致需要临时给 Text 属性赋一个值，查看效果后再删除；
有一个默认折叠的 Expander 控件，但是在设计时无法看到折叠后的效果，只能在运行时查看，或者临时修改 IsExpanded 属性；
Window 的 DataContext 因为在后台代码中赋值，导致在设计时无法看到绑定的数据，也无法在书写绑定时获得智能提示。

如果你有过这样的困扰，那么这篇文章一定可以帮助到你。本文将介绍 WPF 中设计时特性的使用方法，让你在设计时就能看到更多的效果，提高开发效率。

基本概念

设计时特性（Design-Time Attributes）是 WPF 中的一种特性，用于在设计时为控件提供更多的信息，以便在设计时能够更好地预览控件的效果。这一功能其实默认一直都是开启的，只是我想可能很多开发者都没有注意过。比如我们在 WPF 中新建一个 UserControl，那么就会在 XAML 的开头看到类似这样的代码：

1
2
3
4
5
6
7
8


<UserControl x:Class="WpfApp1.MyUserControl"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
 xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
 mc:Ignorable="d" 
 d:DesignHeight="450" d:DesignWidth="800">
</UserControl>

在开头，模板自动为我们添加了很多 XML 命名空间（xmlns），但是很多开发者可能只了解 xmlns 与 xmlns:x 这两个，而往往忽略了另外的几个。但其实另外的几个（xmlns:mc、xmlns:d）就提供了设计时特性的支持。最典型的例子就比如上面的d:DesignHeight和d:DesignWidth，这两个属性就是用来在设计时指定控件的高度和宽度的。这些特性最大的特点就是，它们只在设计时起作用，不会影响运行时的效果。

了解了这些基本概念后，我们就可以开始介绍一些常用的设计时特性了。

常用设计时特性

比如 TextBlock 的 Text 在设计时并没有内容（比如是 DynamicResource 从运行时加载的语言文件中获取，或绑定了 ViewModel 中的属性，但是设计时这个属性没有值，却又想预览字体效果，这时候就可以使用 d:Text 来指定设计时的文本内容：

1

<TextBlock Text="{DynamicResource ResourceKey=HelloWorld}" d:Text="Hello, World!" />

这样在设计时就可以看到 Hello, World! 这个文本了。

如果 TextBlock 的内容是用多个 Run 组合而成，那么我们也可以用这样的方式来实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<TextBlock>
 <d:TextBlock.Inlines>
 <Run Text="Hello, " />
 <Run Text="World!" FontWeight="Bold" />
 </d:TextBlock.Inlines>
</TextBlock>
<!-- 或者也可以用下面将要介绍的虚拟控件 -->
<d:TextBlock>
 <Run Text="Hello, " />
 <d:Run Text="World!" FontWeight="Bold"/>
</d:TextBlock>

其他类似的例子还比如：

有一个只在特殊情况下才会展示的进度条，希望查看它的效果：d:Visibility="Visible"
有一个平时默认折叠的面板，想查看效果：d:IsExpanded="True"
一个用户控件，想给它一个相对合理的默认大小：d:DesignHeight="600" 或 d:Height
一个下拉框，想查看选中项的预览效果：d:SelectedIndex="0"
一个导航用的 ContentControl，我们希望预览导航到某一页的效果，就可以写 d:ContentControl.Content

Info

关于上面的第 5 个例子，为什么我们直接将想要导航的内容以下面要提到的虚拟控件的方式添加到 ContentControl 之中呢？因为通常来说，我们写的导航页面是借助 UserControl 实现的，而它的命名空间通常为 xmlns:local 等。对于这样的命名空间，我们没有办法使用 d: 技巧，所以这里我们选择为 ContentControl 的 Content 属性添加 d: 特性。

虚拟控件

我们不仅可以借助设计时特性来实现控件某些属性的虚拟，还可以虚拟整个控件出来：

1

<d:Button Content="Virtual Button" Style="{StaticResource MyButtonStyle}" />

这样就可以在设计时看到一个虚拟的按钮了，而不需要在运行时才能看到效果。这一技巧可以用来预览按钮的样式。

还有一种常见情形是，我们设计的软件会让用户去手动添加一些项目，从而动态生成对应的控件。对于这样的情况，我们如果能在设计时就看到一些“生成”出来的控件，那么就能更好地开发样式了。此时，我们添加一些虚拟控件，就可以满足这个需求。

1
2
3
4
5
6
7


<ItemsControl>
 <d:ItemsControl.Items>
 <Button Content="Button 1" />
 <Button Content="Button 2" />
 <Button Content="Button 3" />
 </d:ItemsControl.Items>
</ItemsControl>

设计时数据

这段内容可以说是重中之重了。很多开发者苦恼于因为在 Window 的代码后台通过 this.DataContext = new ViewModel(); 来添加 ViewModel，导致在设计时无法看到绑定的数据，也无法获得智能提示。这时候我们可以使用 d:DataContext 来指定设计时的数据：

1
2
3


<Window ...
 d:DataContext="{d:DesignInstance Type=vm:MainViewModel}">
</Window>

DesignInstance 还有一个 IsDesignTimeCreatable 属性，用于指定是否在设计时创建实例。如果设为 True，还将能够在设计时看到一些 ViewModel 中属性的默认值。

或者我们还可以这样写，并且还可以在 XAML 中定制一些 ViewModel 的属性的初始值，便于观察效果：

1
2
3
4
5


<Window ...>
 <d:DataContext>
 <vm:MainViewModel Message="Hello!" />
 </d:DataContext>
</Window>

列表项

如果我们有一个 ListBox，并且想要查看列表项的效果，可以这样：

1
2
3
4
5
6
7
8
9


<ListBox ItemsSource="{Binding Students}">
 <d:ListBox.ItemsSource>
 <x:Array Type="model:Student">
 <model:Student Name="Alice" Age="18" />
 <model:Student Name="Bob" Age="19" />
 <model:Student Name="Charlie" Age="20" />
 </x:Array>
 </d:ListBox.ItemsSource>
</ListBox>

如果不想写 x:Array，而是希望采用传统的为 Items 添加控件的方式添加预览项，也可以这样：

1
2
3
4
5
6
7


<ListBox ItemsSource="{Binding Students}" d:ItemsSource="{x:Null}">
 <ListBox.Items>
 <ListBoxItem>Student 1</ListBoxItem>
 <ListBoxItem>Student 2</ListBoxItem>
 <ListBoxItem>Student 3</ListBoxItem>
 </ListBox.Items>
</ListBox>

这里额外写一个 d:ItemsSource="{x:Null}" 是因为 ItemsSource 和 Items 两个属性不能同时使用，所以我们需要将 ItemsSource 设置为 null，就可以避免这个报错了。

除了这些，如果我们想要预览的是比较简单的数据，或者我们并不非常关心数据的内容及格式，只是希望生成几个项目从而查看样式或模板的书写是否有问题，那么还有一个更简单的方法：

1

<ListBox ItemsSource="{Binding Students}" d:ItemsSource="{d:SampleData ItemCount=5}" />

这样就可以生成 5 个虚拟的列表项了。

参考

如何在 WPF 中实现符合 MVVM 模式的文件拖入功能

Wed, 08 May 2024 00:00:00 +0000

本篇文章对应的教学视频链接：WPF中如何实现符合MVVM模式的文件拖入功能

原始方式

在 WPF 中，实现文件拖入功能并不难。稍微在网上搜索一下，就能够得到答案。比如现在有一个窗口，我们只需要设置它的 AllowDrop 属性为 True，然后在 Drop 事件中处理即可。形如：

1
2
3


<Window ...
 AllowDrop="True"
 Drop="Window_Drop">

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


public partial class MainWindow : Window
{
 public MainWindow()
 {
 InitializeComponent();
 }

 private void Window_Drop(object sender, DragEventArgs e)
 {
 if (e.Data.GetDataPresent(DataFormats.FileDrop))
 {
 var files = (string[])e.Data.GetData(DataFormats.FileDrop);
 // 处理拖入的文件
 }
 }
}

添加视图模型

但问题是，如果现在 Window 拥有一个视图模型（ViewModel），形如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public class MainViewModel : ViewModelBase
{
 private string? _fileName;
 public string? FileName
 {
 get => _fileName;
 set
 {
 _fileName = value;
 OnPropertyChanged(this, nameof(FileName));
 }
 }
}

Info

这里我们假定已经实现了 ViewModelBase 类，它实现了 INotifyPropertyChanged 接口，并提供了 OnPropertyChanged 方法以便于通知属性发生了变化。

然后 Window 上面有一个 TextBox 绑定了这个属性，这又该怎么办呢？

这里有两种比较简单粗暴的方式：

为 TextBox 添加一个 Name，然后在 Window 的 Drop 事件中直接修改 TextBox 的 Text 属性，进而使用依赖属性的一些方法来通知绑定的 ViewModel 属性发生了变化
在 Window 的 Drop 事件中直接修改 ViewModel 的属性（获取 Window.DataContext，并将其转为 MainViewModel 类型），然后在 ViewModel 中实现 INotifyPropertyChanged 接口，进而通知 TextBox 的 Text 属性发生了变化

这两种方式都很直接，而且其实都不违背 MVVM 模式。但是这两种方式并不优雅，所以这里我们借助行为（Behaviors）来实现一个更加优雅且通用的方式。

使用行为

首先，我们需要安装 Microsoft.Xaml.Behaviors.Wpf 包。然后我们可以创建一个 DropFileBehavior 类，形如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


public class DropFileBehavior : Behavior<FrameworkElement>
{
 public string[]? Data
 {
 get => (string[]?)GetValue(FilesProperty);
 set => SetValue(FilesProperty, value);
 }

 public static readonly DependencyProperty FilesProperty = DependencyProperty.Register(
 nameof(Data),
 typeof(string[]),
 typeof(DropFileBehavior),
 new UIPropertyMetadata(null)
 );

 protected override void OnAttached()
 {
 AssociatedObject.AllowDrop = true;
 AssociatedObject.Drop += DropHandler;
 }

 protected override void OnDetaching()
 {
 AssociatedObject.Drop -= DropHandler;
 }

 private void DropHandler(object sender, DragEventArgs e)
 {
 if (e.Data.GetDataPresent(DataFormats.FileDrop))
 {
 Data = (string[])e.Data.GetData(DataFormats.FileDrop);
 }
 }
}

这个行为大致实现的功能是：

当附加到一个 FrameworkElement 上时，将其 AllowDrop 属性设置为 True，并注册 Drop 事件
当拖入文件时，将文件路径保存到 Data 依赖属性中

然后我们就可以在 XAML 中使用这个行为了（因为这里我们声明的 Data 属性是一个数组，所以我们稍微修改 MainViewModel 中相关属性的名称及类型，从而实现绑定功能）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<Window ...
 xmlns:i="http://schemas.microsoft.com/xaml/behaviors"
 xmlns:local="clr-namespace:YourNamespace">

 <i:Interaction.Behaviors>
 <local:DropFileBehavior Data="{Binding FileNames, Mode=OneWayToSource}" />
 </i:Interaction.Behaviors>

 <TextBox Text="{Binding FileNames[0]}" />
</Window>

注意这里，我们在书写行为的 Data 属性的绑定时，使用了 Mode=OneWayToSource，这是因为我们只需要将数据从视图传递到视图模型，而不需要反向传递。并且如果不写 Mode，它默认将会是 OneWay，导致可能无法正确通知到 ViewModel。

制作界面

最后，我们还可以搞一个“酷炫”的界面，形如：

首先，我们可以在窗口中添加这样一个置于上方的控件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


<Grid Name="dropFilePanel" Visibility="Hidden">
 <Border Background="White" Opacity="0.8" />
 <TextBlock HorizontalAlignment="Center"
 VerticalAlignment="Center"
 Text="将文件拖放到此处" />
 <Rectangle Width="200"
 Height="100"
 Stroke="Gray"
 RadiusX="10"
 RadiusY="10"
 StrokeDashArray="3,4"
 StrokeThickness="2" />
</Grid>

同时，因为我们现在有了这个专门的用于放置文件的面板，所以我们可以将之前添加给窗口的行为转移到它身上，形如：

1
2
3
4
5


<Grid Name="dropFilePanel" Visibility="Hidden">
 <i:Interaction.Behaviors>
 <local:DropFileBehavior Data="{Binding FileNames, Mode=OneWayToSource}" />
 </i:Interaction.Behaviors>
 ...

但是我们要控制它在合适的时机出现与消失。这里我们可以使用触发器与行为来快速地实现这一效果。具体来说，我们可以给窗口添加这样的触发器：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<Window ...
 xmlns:b="http://schemas.microsoft.com/xaml/behaviors">
 <b:Interaction.Triggers>
 <b:EventTrigger EventName="DragEnter">
 <b:ChangePropertyAction TargetObject="{Binding ElementName=dropFilePanel}" PropertyName="Visibility" Value="Visible" />
 </b:EventTrigger>
 <b:EventTrigger EventName="DragLeave">
 <b:ChangePropertyAction TargetObject="{Binding ElementName=dropFilePanel}" PropertyName="Visibility" Value="Hidden" />
 </b:EventTrigger>
 </b:Interaction.Triggers>
 ...

这样，当鼠标拖入窗口时，dropFilePanel 就会显示出来；当鼠标拖出窗口时，dropFilePanel 就会被隐藏。

实际测试后会发现，当我们将文件拖到上方并松开左键后，虽然行为得到了正确的响应，但面板并没有消失。这是因为我们上面写的触发器只会在鼠标拖动状态离开窗口后才会隐藏面板。所以这里，我们可以再为面板添加一个触发器，并在它触发了 Drop 事件后将自身隐藏：

1
2
3
4
5
6


<Grid Name="dropFilePanel" Visibility="Hidden">
 <b:Interaction.Triggers>
 <b:EventTrigger EventName="Drop">
 <b:ChangePropertyAction PropertyName="Visibility" Value="Hidden" />
 </b:EventTrigger>
 </b:Interaction.Triggers>

这样，上面动图中的效果就实现了。

总结

WPF 开发必然会经常和控件的事件打交道。但很多时候，如果我们希望遵循 MVVM 模式，可能就会不知所措。相信大家通过这篇文章的代码，都能够充分领略到使用触发器与行为的强大之处。当然，这里只是一个简单的例子，实际开发中，我们还可以为上面的例子添加更多丰富的功能及特效。这些就有待大家的探索了。

大家如果有什么自己的好方法，也欢迎在文章评论区留言，分享给大家。

WPF on 寒流の编程笔记

如何正确使用 WPF 中 Application 的 MainWindow 及 ShutdownMode 属性

单例模式

配合 ShutDownMode 使用

为什么 MainWindow 属性通常就是 MainWindow？

ShutdownMode 是什么？

第一个窗口不是 MainWindow 该怎么办？

更优雅的方式

总结

原生 WPF 框架中体现出的设计模式

观察者模式

桥接模式

装饰器模式

适配器模式

责任链模式

其他设计模式

总结

借助 ObservableCollections 获得更多具有通知功能的集合类型

安装

支持批量操作的可观测集合

创建集合视图

可观测的字典

可观测的队列

可观测的环形缓冲区

线程安全

总结

WPF 中的 ContentControl 及 ContentPresenter 有何异同？

二者的共同点

二者的区别

它们的基类不同

它们的功能不同

总结

WPF 中 ObjectDataProvider 的一些有趣用法

基本用法

创建对象

调用方法

给定实例

工厂模式

经典用法

绑定枚举类型到下拉选单

为下拉选单提供整数数据源

总结

如何在 WPF 中高效布局多行多列的控件

最传统的方式：Grid

外层使用 UniformGrid

外层使用 StackPanel

使用更高级的 Grid

总结

WPF 值转换器（ValueConverter）的一些实用技巧

使用 WPF 内置的值转换器

将值转换器声明为单例

将值转换器声明在 App.xaml 中

使用 MarkupExtension 简化值转换器的使用

返回 DoNothing 与 UnsetValue

借助 CultureInfo 实现多语言支持

仿照 Avalonia UI 实现一个 FuncValueConverter

其他第三方库

总结

WPF 中的 Name 与 x:Name 究竟是什么区别？

本质不同，但却又几乎相同

x:Name 本质上意味着什么？

总结

参考

WPF 设计时特性的实用技巧

基本概念

常用设计时特性

虚拟控件

设计时数据

列表项

更多功能

参考

如何在 WPF 中实现符合 MVVM 模式的文件拖入功能

原始方式

添加视图模型

使用行为

制作界面

总结

第一个窗口不是 `MainWindow` 该怎么办？

使用 `MarkupExtension` 简化值转换器的使用