why TTN_NEEDTEXTW but not TTN_NEEDTEXTA?

Question

This is an old problem that I've never figured out - wondered if someone here might happen to know the answer off of the top of your head...

In some parts of our software (MFC/Win32/MBCS) my code will only receive

TTN_NEEDTEXTW

In other parts of our software, I'll receive the MBCS correct message

TTN_NEEDTEXTA

It makes no sense to me.

I understand that our software can be compiled Unicode or not (we are set to use Multibyte character set). And I have the vague recollection that each window can be constructed Unicode or not, though this is a vague memory, nothing concrete.

Does anyone know why we'd be getting the wide version message some places in our code, despite being compiled as multibyte?

NOTES:

We're definitely not sending this message - presumably the ToolTip control is.
We're definitely only receiving the (W) message in some places, and definitely only receiving the (A) message in others.
I'm certain that all compilation modules use MBCS, not Unicode, and that the build targets all specify MBCS not Unicode.
This seems to happen only for CMainFrame hosted windows and controls. i.e. Windows outside of the main frame can use narrow versions (say in a dialog box).

score 5 · Accepted Answer · answered Sep 25 '12 at 19:48

5

The common control sends you a WM_NOTIFYFORMAT message to ask you "Would you prefer to receive MBCS notifications or Unicode notifications?" The default is to respond based on whether the window was created via CreateWindowExW or CreateWindowExA.

answered Sep 25 '12 at 19:48

Raymond Chen

44,448
11
96
135

Minor nit: the use of RegisterClassExA/RegisterClassExW determines a window's unicode status. – arx Sep 25 '12 at 19:59
This makes sense, but so far no luck on seeing why our CFrameWnd derived window and hosted controls would be receiving the W variant for a MBCS build. Tracing startup shows that RegisterClassA and CreateWindowA are being called during class registration & creation. Even stranger still, WM_NOTIFYFORMAT is only referred to in our code for tracing purposes, and in the VC++ include paths to define its numeric identity & for the ON_WM_NOTIFYFORMAT() macro. Maybe when the tooltip control is being initialized there is another way to tell it what message type to send? – Mordachai Sep 26 '12 at 13:35
Is it possible that the tooltip is being created by some other code? (For example, the listview control creates its own tooltip.) – Raymond Chen Sep 26 '12 at 21:09
So far no luck figuring this out. It's an old MFC multi doc app, with both the CMainFrame and the the only view CMyView being entities that seem to get only W variations in the tooltip notifications. Dialogs, property sheets all get the correct A variations. The CMyView is a CView derivative, no CListView or other complications there. Sorry, obviously we're doing something to get the wrong message - and it's a big app, so I'll have to poke at this as/when I have time. Not a big deal, just one of those "huh?" moments, where I didn't know the rules so hard to interpret the results... – Mordachai Sep 28 '12 at 18:20

score 1 · Answer 2 · answered May 06 '21 at 15:01

With an MFC ansi app (that handles unicode data), I had this issue with CStatic derived classes and tooltip where I was getting TTN_NEEDTEXTA instead of, in my case, the desired TTN_NEEDTEXTW.

Using the accepted answer, managed to get TTN_NEEDTEXTW.

BEGIN_MESSAGE_MAP(CStaticDerived, CStatic)
ON_WM_NOTIFYFORMAT()
ON_NOTIFY_EX_RANGE(TTN_NEEDTEXTW, 0, 0xFFFF, OnTTNeedText)
END_MESSAGE_MAP()

UINT CStaticDerived::OnNotifyFormat(
    CWnd *pWnd,
    UINT nCommand) {

    if (pWnd->m_hWnd
            == AfxGetModuleThreadState()->m_pToolTip->m_hWnd) {
        // want TTN_NEEDTEXTW for tooltips
        return NFR_UNICODE;
    }

    return __super::OnNotifyFormat(pWnd, nCommand);
}

why TTN_NEEDTEXTW but not TTN_NEEDTEXTA?

2 Answers2