c - Win7 中的 SendMessageA 和 SendMessageW 从 WinXP 迁移而来

Question

编辑:下面发布了工作代码，非工作代码被注释掉了。您必须使用与在 Win7 中创建它们时相同的 CHAR_T 从窗口检索数据。

我有一个用 C 编写的对话框，它在 WinXP 中运行良好，但无法从 Win7 中的 unicode 编辑控件收集用户输入。问题出现在第一次调用 SendMessageW 时，如下所示:

/* handles to controls */
HWND hDomainEdit;
HWND hOtherEdit;
HWND hTextOut;
HWND hButton;
/* buffers to receive input */
WCHAR wszDomain[256];
CHAR szOtherInput[512];
CHAR szBuffer[512]; //added to hold temporary value of wszDomain
/* a test string */
const CHAR szTest[] = "This is a test of SendMessageA."

BOOL dialogProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam) {

    if (message == WM_INIT) {
        /* get all the handles shown above, then... */
        SendMessageA(hTextOut, WM_SETTEXT, 0, (LPARAM) szTest);
        /* worked fine */
        /* do a few other things */
    } else if (message == WM_COMMAND) {
        /* are some other conditions are true?  they sure are */
        /* time to collect a bunch of input from controls */
        int cchResultLen = (int) SendMessageA(hOtherEdit, WM_GETTEXT, 512, (LPARAM) szOtherInput);
        /* cchResultLen is correctly the length of the user input */
        /* cchResultLen = (int) SendMessageW(hDomainEdit, WM_GETTEXT, 256, (LPARAM) wszDomain); */
        /* begin new code */
        cchResultLen = (int) SendMessageA(hDomainEdit, WM_GETTEXT, 512, (LPARAM) szBuffer);
        cchResultLen = MultiByteToWideChar(CP_UTF8, 0, szBuffer, cchResultLen, wszDomain, 256);
        wszDomain[cchResultLen] = 0; /* above doesn't terminate string */
        /* after SendMessageW(), cchResultLen was 0, no string transferred, no error
           message.  using SendMessageA, all is well. */
    }
}

似乎 SendMessageA 与 message = WM_GETTEXT 或 WM_SETTEXT 一起工作了多次，突然间，当需要一个宽字符串时，SendMessageW 失败了。现在，我知道每个人都认为您应该选择一个 CHAR_T 并始终使用 SendMessage 坚持使用它，但事实并非如此； Win32.hlp 明确指出，可以通过手动调用各个函数在同一程序中同时使用这两个函数。我确信其他人已经准备好说控件本身是或将致力于一个特定的 CHAR_T，但在 WinXP 中情况并非如此，它工作得很好。该特定编辑控件也从未明确设置为 ASCII 字符串。

程序与 WinHttp 交互，需要所有 WCHAR 字符串，这就是 SendMessageW 的用武之地。其余输入仅在内部使用，主要是带有单位标签的解析整数，在 ASCII 中更方便和高效，如果没有其他原因，只是因为程序最初是这样写的。

那怎么办？他们真的改变了像 SendMessage 这样不可或缺的东西以使其不兼容吗？如果是这样，它是一个已知的 bug 和解决方法，还是能够随意切换 CHAR_T 的功能已弃用？在使用 SendMessageA 获取输入后，是否有比手动将输入扩展到 WCHAR 更简单的方法？

Answer 1

我的理解是，如果您使用调试器单步执行代码，您就会明白原因。

首先，您先后拥有的两个 SendMessages，它们使用不同的窗口句柄，因此它们不会给您相同的结果。让我们谈谈给您带来问题的那个:

cchResultLen = (int) SendMessageW(hDomainEdit, WM_GETTEXT, 256, (LPARAM) wszDomain);
// cchResultLen is ZERO!  wszDomain[0] is null.  Edit control is not empty 

与调试器一起站在这条线上，检查您的 hDomainEdit 变量。也许它无效，如 NULL 或被其他代码损坏。这将解释无效句柄和零结果。