Win32控件混用ANSI与WideChar API的问题及解决探索

核心疑问 #

• 处理Win32控件时，能否混用*ANSI版（A后缀）与宽字符版（W后缀）*API？
• 是否有文档说明交替调用SetWindowTextA和SetWindowTextW的可行性？
• 使用SetWindowTextW设置文本，是否必须用CreateWindowW创建编辑框？

问题现象 #

使用SetWindowTextW设置带重音的字符（如'è'）时，字符会被转换为'e'；参考相关方案修改代码后，控件内容直接为空。测试代码如下：

savedWndProc = (WNDPROC)GetWindowLong (ctlHwnd, GWL_WNDPROC);
  
SetWindowLongPtrW (ctlHwnd, GWLP_WNDPROC, (LONG_PTR)DefWindowProcW);  // 或SetWindowLong (ctlHwnd, GWL_WNDPROC, (long)DefWindowProcW);
result = SetWindowTextW (ctlHwnd, buffPtr);
SetWindowLong (ctlHwnd, GWL_WNDPROC, (long)savedWndProc);

排查发现if (GetWindowLong(ctlHwnd, GWL_WNDPROC) == DefWindowProc)的判断永远不成立，推测编辑控件有专属的默认窗口过程（而非DefWindowProc）。

解决与分析过程 #

1. 临时可行方案：创建不可见的CreateWindowW编辑框获取其窗口过程，调用以下代码后'è'可正常显示：

CallWindowProcW (origEditProcW, ctlHwnd, WM_SETTEXT, 0L, (long)buffPtr);

2. 根本原因定位：SetWindowTextW最终会向窗口发送WM_SETTEXT消息，但由于项目是ANSI版，所有编辑框的自定义窗口过程在处理未捕获的消息时，会调用CallWindowProcA，导致Unicode字符串被转换为本地编码，特殊字符丢失。若不子类化编辑框，SetWindowTextW可正常工作。

3. 最终解决方法：在自定义窗口过程中，针对WM_SETTEXT和WM_GETTEXT消息，显式调用CallWindowProcW，问题彻底解决。

额外验证与疑问 #

使用SetWindowTextW时'è'变为'e'而非崩溃或乱码，是因为编辑控件的过程通过CallWindowProcA做了编码转换。但断点中观察到lParam是普通C字符串，疑惑SetWindowTextW为何会适配CallWindowProcA的调用逻辑。最终在子类化场景下，仅能通过直接调用宽字符版窗口过程实现Unicode文本设置：

CallWindowProcW (origEditProc, ctlHwnd, WM_SETTEXT, 0L, (long)wcharBuffPtr);

而非使用：

SetWindowTextW (ctlHwnd, wcharBuffPtr);

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