+1  A: 

Is your whole application using unicode? Else you might read this "Microsoft article". Especially the "Twelve steps to Unicode-enabling" section.

Or try like this guy did

Robert Scott Unicode Tooltips

jitter
+3  A: 

The fact that you get the TTN_GETDISPINFO notification code but not TTN_GETDISPINFOW indicates that your project is setup to "Use Multi-Byte Character Set".

Check the projects property pages: "Configuration Properties" -> "General" -> "Character Set"
This property should be set to "Use Unicode Character Set".

Volker Voecking
+2  A: 

Thanks for the Robert Scott link. I found a way to solve it now.

In short, the trick was to make sure the receiving window was a unicode window and register a unicode window procedure for it.

The problem was that I did not have a unicode WindowProc() for my parent window handling the TTN_GETDISPINFOW notification message. Since this window (class) was created with RegisterClassEx()/CreateWindowEx() and not RegisterClassExW()/CreateWindowExW(), it did not have registered window procedure for unicode messages.

To get around the problem I changed ti.hwnd from hwnd_main to hwnd_control when sending TTM_ADDTOOLW, resulting in the control's window procedure receving the notifications instead of its parent. In order to intercept the unicode events now sent to the control's window procedure, I subclassed it using SetWindowLongW(hwnd_control, GWL_WNDPROC, (LONG) NewControlWndProc).

Note that hwnd_control is a standard "LISTBOX" window created with CreateWindowExW() and is therefore unicode-aware, since all buildt-in Windows classes are automatically registered in both unicode and ANSI version by the system.

Anders Sandvig
Quite likely the correct solution, I was about to post the same. Windows internally is Unicode, but will marshall API arguments when running an MBCS (aka ANSI aka Windows95) application.
MSalters