忽略编辑控件的 WM_GETTEXTLENGTH 潜在的不准确是否安全？

Question

此文档页面说

发送 WM_GETTEXTLENGTH 消息时，DefWindowProc 函数返回文本的长度（以字符为单位）。在某些条件下，DefWindowProc 函数返回的值大于文本的实际长度。这种情况发生在 ANSI 和 Unicode 的某些混合中，这是由于系统允许文本中可能存在双字节字符集 (DBCS) 字符。

我假设这些情况都不会出现在 WCHAR 编辑控件中，因为它只是 WCHAR。

我想忽略它们并直接使用 WM_GETTEXTLENGTH 作为我的长度。如果碰巧 WM_GETTEXTLENGTH 不只是执行 strlen 操作来获取其值，而是预先计算它，这将有利于性能。我想我得看看 ghidra 中记事本的反编译才能找到答案。

Answer 1

好吧，我仍然不知道依赖 WM_GETTEXTLENGTH 返回的长度是否安全，但它肯定比对从 WM_GETHANDLE+LocalLock 获得的指针执行 wcslen 快得多。

From a benchmark of a 4107893 char file. 
Time is total seconds taken to compute the length 512 times:

WM_GETTEXTLENGTH:
    Length: 4107893
    Time: 0.000058
wcslen:
    Length: 4107893
    Time: 0.623284

不过，WM_GETTEXT/wcslen 的性能可能不是问题。我意识到我的应用程序遇到的缓慢实际上与记事本遇到的速度相同，并且当我在大型文档上调用 WM_REPLACESEL 时会发生这种情况。由于某种原因，用该消息替换大型文档中的任意数量的文本都非常慢。