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
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
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".
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.