Win32程序已设PerMonitor DPI感知，未收到WM_DPICHANGED消息

一、无缩放时未收到WM_DPICHANGED的原因 #

你的推测核心正确，需明确Windows高DPI逻辑中的关键概念区别：

• 有效DPI：Windows给应用提供的基准DPI，默认值为96，仅当用户在显示设置中调整缩放比例时，才会根据缩放因子生成新的有效DPI（如150%缩放对应144DPI）。
• 物理DPI（raw/angular）：显示器硬件的实际像素密度，系统不会直接以此触发DPI变更通知。

PerMonitor类型的DPI感知，核心是响应有效DPI的变化。当两台显示器均设为100%缩放时，有效DPI均为96，系统判定窗口所处环境的DPI未发生变化，因此不会发送WM_DPICHANGED消息，这是符合Windows高DPI规则的正常行为，不存在矛盾。

二、编辑2中收不到WM_DPICHANGED的排查方向 #

结合你提到的“之前能收到、重构后失效，且高DPI屏启动可获取正确缩放”的情况，重点排查以下点：

1. 清单配置的语法错误：你提供的清单代码末尾存在多余双引号，属于XML语法错误：

   <dpiAwareness>PerMonitorV2,PerMonitor</dpiAwareness>"
   

   该错误会导致windowsSettings节点解析失败，进程DPI感知可能降级到旧的PerMonitor模式而非PerMonitorV2，而V2模式对跨显示器DPI变化的通知逻辑更完善。请立即修复，去掉多余双引号。

2. 窗口与进程的DPI感知上下文不一致：即使进程是PerMonitor感知，个别窗口可能被显式设置了不同的DPI上下文。在窗口创建后调用GetWindowDpiAwarenessContext()，再用GetAwarenessFromDpiAwarenessContext()验证，确保窗口处于DPI_AWARENESS_PER_MONITOR_AWARE_V2状态；若不一致，可调用SetWindowDpiAwarenessContext()强制设置为V2上下文。

3. WM_DPICHANGED消息被拦截或遗漏：检查窗口过程函数，确认没有在基类或其他逻辑中吞掉该消息。处理消息时，必须调用SetWindowPos()应用消息参数提供的新窗口矩形，否则系统可能判定窗口未完成适配，后续不再发送通知。

4. 系统DPI缓存问题：多次修改缩放比例后，系统可能存在缓存未更新的情况，尝试重启系统后再测试。

5. 窗口移动的触发条件：Windows仅当窗口**大部分区域（通常超50%）**移入另一台显示器时，才会触发WM_DPICHANGED，测试时确保窗口完全移入目标显示器。

三、高DPI感知应用的开发规范 #

1. 正确配置清单：确保清单无语法错误，优先使用PerMonitorV2（支持Windows 10 1607及以上），标准配置示例：

   <asmv3:windowsSettings xmlns="https://schemas.microsoft.com/SMI/2016/WindowsSettings">
       <dpiAwareness>PerMonitorV2,PerMonitor</dpiAwareness>
   </asmv3:windowsSettings>
   

2. 不依赖单一消息通知：不要仅靠WM_DPICHANGED处理DPI变化，在窗口移动、尺寸变更、系统缩放调整后，主动执行以下步骤获取当前DPI：

   • 调用MonitorFromWindow()获取窗口所在显示器句柄
   • 调用GetDpiForMonitor()（指定MDT_EFFECTIVE_DPI参数）获取该显示器的有效DPI
   • 根据新DPI重新计算UI元素的大小与位置

3. 避免硬编码像素值：所有UI布局的尺寸、位置均基于逻辑像素（以96DPI为基准），通过MulDiv()函数转换为物理像素：

   int logicalSize = 100;
   int currentDpi = 144; // 当前有效DPI
   int physicalSize = MulDiv(logicalSize, currentDpi, 96);
   

4. 处理窗口创建时的DPI：在窗口初始化阶段，立即获取所在显示器的有效DPI，基于该DPI创建控件、设置初始布局，避免启动时UI模糊或尺寸错误。

5. 注册窗口类时添加必要属性：确保窗口类包含CS_HREDRAW | CS_VREDRAW，保证窗口大小变化时自动重绘，适配DPI变化后的布局。

内容的提问来源于stack exchange，提问作者Robinson