MFC如何解释SetWindowTextW(LPCTSTR)? [英] How does MFC interpret SetWindowTextW(LPCTSTR)?

查看:357
本文介绍了MFC如何解释SetWindowTextW(LPCTSTR)?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在MFC中,没有定义为CWnd::SetWindowTextA/CWnd::SetWindowTextW的方法,但是以下代码将根据Unicode设置进行编译并正确运行:

In MFC there are no methods defined as CWnd::SetWindowTextA/CWnd::SetWindowTextW, yet the following code will compile and run correctly depending on Unicode settings:

//UNICODE is defined
BOOL CMyDialog::OnInitDialog()
{
    CDialogEx::OnInitDialog();

    //this line won't compile as expected
    //SetWindowTextA(L"ANSI");

    //this line compiles, but CWnd::SetWindowTextW doesn't exits
    //SetWindowTextW ends up calling CWnd::SetWindowText
    SetWindowTextW(L"Unicode");
    return TRUE;
}

//UNICODE is not defined
BOOL CMyDialog::OnInitDialog()
{
    CDialogEx::OnInitDialog(); 

    //this line compiles, but CWnd::SetWindowTextA doesn't exits!
    //SetWindowTextA ends up calling CWnd::SetWindowText
    SetWindowTextA("ANSI");

    //this line won't compile as expected
    //SetWindowTextW(L"Unicode");
    return TRUE;
}

根据宏将SetWindowText映射到SetWindowTextA/SetWindowTextW是有意义的.但是我不明白如何将wnd->SetWindowTextA/wnd->SetWindowTextW映射回CWnd::SetWindowText.

It makes sense that SetWindowText is mapped in to SetWindowTextA/SetWindowTextW depending on the macro. But I don't understand how wnd->SetWindowTextA/wnd->SetWindowTextW get mapped back in to CWnd::SetWindowText.

推荐答案

这是WinUser.h中的宏声明的副作用.它不仅适用于Windows API的全局函数声明,而且还适用于出现在代码中的任何其他名为SetWindowText的标识符:全局,本地或类范围.

It's a side effect of the macro declaration in WinUser.h. It applies not only to the global function declaration for the Windows API, but also any other identifier named SetWindowText that appears in code: global, local, or class scope.

#ifdef UNICODE
#define SetWindowText  SetWindowTextW
#else
#define SetWindowText  SetWindowTextA
#endif // !UNICODE

因此,任何声明名为SetWindowText方法的C ++类都将获得预处理器隐式转换的所有方法.

So any C++ class that declares a method called SetWindowText gets all that method implicitly converted by the preprocessor.

我没有安装MFC,但是我确实知道ATL上的CWindow类存在此方法,并且定义如下.

I don't have MFC installed, but I do know this method exists for the CWindow class on ATL and is defined as follows.

    class CWindow
    {
    public:
        ...

        BOOL SetWindowText(_In_z_ LPCTSTR lpszString) throw()
        {
            ATLASSERT(::IsWindow(m_hWnd));
            return ::SetWindowText(m_hWnd, lpszString);
        }

        ...
    };

但是在编译时,上面的代码(用于调试版本)将被预处理器转换为如下代码:

But at compile time, the above code (for a debug build) is going to get converted by the preprocessor into something like the following:

BOOL SetWindowTextW(  LPCTSTR lpszString) throw()
{
    (void)( (!!((::IsWindow(m_hWnd)))) || (1 != _CrtDbgReportW(2, L"c:\\program files...
    return ::SetWindowTextW(m_hWnd, lpszString);
}

具有讽刺意味的是,LPCTSTR方法参数是类型定义的,而不是宏替换,但是您明白了.

Ironically, the LPCTSTR method parameter is typedef'd instead of being a macro replacement, but you get the idea.

如果您有足够大的Windows应用程序,则很有可能您自己定义的现有C ++类之一具有与Windows API匹配的方法或成员变量.而且得到了相同的待遇.

If you have a large enough Windows application, chances are very high that one of your existing C++ classes that you defined yourself has a method or member variable that matches a Windows API. And it's getting the same treatment.

这篇关于MFC如何解释SetWindowTextW(LPCTSTR)?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆