【笔记】在WPF中CommandManager的功能和应用场景详细介绍

CommandManager（System.Windows.Input.CommandManager）是 WPF 命令体系的"调度/刷新中枢"，核心职责是 把输入（键盘、鼠标、菜单点击等）映射到命令（ICommand / RoutedCommand）并驱动命令的 CanExecute/Execute 查询与执行，同时在 UI 状态变化时刷新按钮、菜单等控件的可用性。

1) 它解决的问题是什么

1.1 命令的统一入口（解耦 UI 与逻辑）

相比直接在按钮 Click 写事件处理，命令模式让你能：

在多个 UI 元素上复用同一个动作（Toolbar 按钮、菜单项、快捷键、右键菜单）
把"触发方式"从"执行逻辑"中剥离
通过 CommandParameter 传参、用 CommandTarget 指定目标

1.2 自动维护可用性（Enabled/Disabled）

WPF 的 ButtonBase、MenuItem 等实现了 ICommandSource，会根据命令的 CanExecute 自动把 IsEnabled 置为 true/false。

而 CommandManager 就负责在合适的时机触发/协调 CanExecute 的重新查询（requery）。

2) `CommandManager` 的主要能力点

2.1 命令路由与绑定（`CommandBinding`）

WPF 命令体系中常见两类命令：

普通 ICommand ：典型是 MVVM 的 RelayCommand/DelegateCommand
RoutedCommand / RoutedUICommand：WPF 原生路由命令（支持在可视树上"找能处理命令的元素"）

对于 RoutedCommand，CommandManager 会沿着 CommandTarget（或当前焦点/路由路径）查找 CommandBinding 来决定：

谁处理 Executed
谁回答 CanExecute

CommandBinding 的两个关键事件：

CanExecute：决定能不能执行（影响 UI 是否禁用）
Executed：真正执行

2.2 输入手势到命令（`InputBinding` / `KeyBinding` / `MouseBinding`）

CommandManager 结合 InputBinding 实现：

Ctrl+S 触发保存
Delete 触发删除
鼠标手势触发某个命令

这让同一命令同时可以被"点击按钮"或"按快捷键"触发。

2.3 重新查询 `CanExecute`（Requery）

CommandManager 最常被提到的就是：

CommandManager.RequerySuggested（事件）
CommandManager.InvalidateRequerySuggested()（方法）

它的意义是：通知命令源（按钮/菜单等）"你们该重新问一遍 CanExecute 了"。

典型现象：

你改变了某个 ViewModel 状态，但按钮没立即变灰/变亮
→ 往往是没有触发 requery

对 RoutedCommand + CommandBinding 的场景，CommandManager 参与度很高；对纯 MVVM ICommand 的场景，通常通过 INotifyPropertyChanged + CanExecuteChanged 来驱动，但很多 RelayCommand 会"挂钩" CommandManager.RequerySuggested 来省事。

3) 常见应用场景（按典型 WPF 设计来划分）

场景 A：窗口级/控件级快捷键体系

例如编辑器/画布控件常需要：

Ctrl+Z 撤销
Ctrl+Y 重做
Delete 删除选中图形
Ctrl+C/V 复制粘贴

用 CommandManager + InputBindings/CommandBindings 可以把这些快捷键绑定在控件或窗口上，不需要在 KeyDown 里硬编码大量分支。

场景 B：菜单、工具栏、右键菜单复用同一套动作

同一命令同时被：

MenuItem
ToolBar Button
ContextMenu Item
快捷键

触发，且可用性统一由 CanExecute 控制。

场景 C：文档编辑/选择状态驱动 Enabled

例如：

没有选中对象时，"删除""剪切"禁用
剪贴板无内容时，"粘贴"禁用
当前状态不允许操作（只读/锁定）则禁用相关命令

这类"可用性"变化多、频繁，靠 CommandManager 统一刷新更合理。

场景 D：控件库/组件希望提供可扩展命令点

WPF 控件库通常会暴露 RoutedUICommand（带 Text）：

让使用者能在外部添加 CommandBinding 来覆盖/扩展行为
让命令在可视树上路由，便于"谁有焦点谁处理"

4) `CommandManager` 与 MVVM 的关系（该不该用）

4.1 纯 MVVM ICommand

如果使用的是自定义 ICommand（比如 RelayCommand）并且你自己在状态变化时手动触发 CanExecuteChanged，那么不一定需要直接依赖 CommandManager。

4.2 `CommandManager` 参与的 MVVM（常见实现）

很多 RelayCommand 会这样实现 CanExecuteChanged：

add 时订阅 CommandManager.RequerySuggested
remove 时退订
这样 WPF 在合适时机会自动触发 CanExecute 刷新

优点：简单

缺点：刷新时机不完全可控，有时需要你调用 InvalidateRequerySuggested() 强制刷新。

5) 常见坑与实践建议

按钮不刷新 IsEnabled
- 对 RoutedCommand：通常是路由目标不对/没有 CommandBinding，或需要触发 requery
- 对 RelayCommand：确认是否触发了 CanExecuteChanged（或是否挂钩 RequerySuggested）
频繁调用 InvalidateRequerySuggested()
- 它会触发全局 requery，可能导致 UI 频繁查询 CanExecute（性能/卡顿）
- 建议：状态变化时调用一次即可；或用更精细的 CanExecuteChanged 事件
CommandTarget / Focus 导致命令"找不到处理者"
- RoutedCommand 默认会从焦点元素/目标元素开始向上路由
- 如果你的命令绑定在某个父容器上，但焦点在别处，可能会路由不到
- 需要设置 CommandTarget 或把 CommandBinding 放在更合适的元素上（例如窗口根）