I have already verified that I can force a wide character version of
SetWindowText by explicitly calling it SetWindowTextW and using a wide character
string for the second parameter. So what about tooltips? Here is my existing
handler for the tooltip notification message:
case WM_NOTIFY:
LPNMHDR pnmh = (LPNMHDR)lParam;
if(pnmh->code == TTN_NEEDTEXT)
{
LPTOOLTIPTEXT lpttt = (LPTOOLTIPTEXT)lParam;
LPSTR pReply = (***some char string***);
lstrcpy(lpttt->szText,pReply);
}
break;
Now the message TTN_NEEDTEXT is defined as TTN_NEEDTEXTA for a non-Unicode
compile and TTN_NEEDTEXTW for a Unicode compile. But if I change my
TTN_NEEDTEXT to TTN_NEEDTEXTW I have verified that such a message is never sent
to my window proc. So something is telling the system that my code is not
Unicode. But what is it? My toolbar is created with:
hwndTB = CreateToolbarEx(
hwndParent,
(WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS |
CCS_TOP | TBSTYLE_TOOLTIPS),
1, // Child window ID #
22, // number of images in TOOLS.BMP
instMain,
207, // Bitmap resource ID
tbb, // pointer to TBBUTTON array
sizeof(tbb)/sizeof(TBBUTTON), // iNumButtons
0,0,
24, // dxBitmap
24, // dyBitmap
sizeof(TBBUTTON));
I see nothing in this call that tells the system whether I am Unicode or not, so
why do I just get TTN_NNEDTEXTA notification messages and not TTN_NEEDTEXTW
messages? I am running on WinXP.
Any idea as to the correct method to force Unicode tooltips without converting
the whole project over to Unicode?
Robert Scott
Ypsilanti, Michigan
I know about the message because there is (was) a bug in MFC, but I forget
the details of the bug; I understood the problem quite well in the past but
now I have forgotten. I hope it is easy enough to find the relevant message
using the technique I describe above.
"Robert Scott" <---@---> wrote in message
news:4756996a...@newsgroups.comcast.net...
"Robert Scott" <---@---> wrote in message
news:4756996a...@newsgroups.comcast.net...
>Since there are not separate CreateToolbarEx functions for Unicode and not
>for Unicode, I suspect that the tooltips use Unicode if and only if the
>window uses Unicode.
Yes, I am beginning to suspect that the Unicode information is being extracted
from the parent window (the first parameter to CreateToolbarEx). Anyway, this
is all academic now because I have resigned myself to the fact that if I want to
support Unicode in tooltips I will have to convert the entire application to
Unicode (at least as far as any string handling that involves the Win32 API).
Robert Scott
Ypsilanti, Michigan
Robert Scott
Ypsilanti, Michigan
"Robert Scott" <---@---> wrote in message
news:4759fb29...@newsgroups.comcast.net...
>All 65536 characters of what font? What font are you using for the Tooltips?
I have not explicitly selected a font. So whatever default font tooltips use is
what I have.
Robert Scott
Ypsilanti, Michigan
Then probably the font is not a Unicode font with the characters you need. I
am sorry I cannot help more than that; I hope someone can.
Based on the documentation of Tooltip Controls, you can send them a
WM_GETFONT. That can be done for diagnostic purposes. If the font is not a
Unicode font with the characters you need, then you can be confident that
you need to change the font. I am not sure how to do that, but based on the
documentation, it appears that a WM_SETFONT will help.
>"Robert Scott" <---@---> wrote in message
>Based on the documentation of Tooltip Controls, you can send them a
>WM_GETFONT. That can be done for diagnostic purposes. If the font is not a
>Unicode font with the characters you need, then you can be confident that
>you need to change the font. I am not sure how to do that, but based on the
>documentation, it appears that a WM_SETFONT will help.
Well, I found that the HFONT does not tell you much until it is selected into a
DC. But you did point me in the right direction, because I found TB_GETTOOLTIPS
to get the handle to the tooltip control from the toolbar window handle. Then I
used GetDC() on that tooltip handle to get a DC for it. Using the DC I finally
called GetTextFace(), which yielded "System". No surprise there, I guess. So
apparently "System" is not a Unicode font. So my plan is now to get a specific
Unicode font with the Asian characters I need, then after the toolbar is
created, use CreateFont() and WM_SETFONT on the tooltips handle. I'll let you
know how it goes.
Robert Scott
Ypsilanti, Michigan
Thanks for all the advice!
Robert Scott
Ypsilanti, Michigan
Back then I reported here that I had successfully gotten a little test program
to display Unicode tooltips by getting a handle to the tooltips window using the
TB_GETTOOLTIPS message to the toolbar. Then I sent WM_SETFONT to the tooltip
window. Furthermore, the test application was compiled with the UNICODE and
_UNICODE symbols defined.
Then I began to apply what I had learned to my real application. It seemed that
I had to convert the entire application to Unicode. I soon realized that it
would be a huge job because the application used strings in many many places.
And if I really had to convert the entire application over to Unicode, I would
have to examine each and every instance where a string is used to see if it had
to be converted and if different string-handling functions had to be used. Of
course this would have been much simpler if I had written the application
initially using the Unicode-neutral functions. But I was ignorant of this stuff
10 years ago when I first wrote this application.
Fortunately I have found that it is not necessary to convert the entire
appliction to Unicode to get Unicode tooltips. Here is what I did.
I segregated into one file the following functions:
1. MyRegisterClass (where I call RegisterClass for my main window class)
2. MyCreateWindow (where I call CreateWindow for my main window)
3. MyDefWindowProc (where I call DefWindowProc for all message that my WndProc
does not handle)
4. MyInitToolbar (where I call CreateToolbarEx)
5. MyWmNotify (where I respond to the WM_NOTIFY message by checking for
TTN_NEETTEXT and if so, responding with the correct Unicode tooltip text)
This one file was compiled with the UNICODE and _UNICODE symbols defined before
any windows includes. Of course I could not use the pre-compiled header that I
used for all the other files in my application because of this difference. But
this allowed me to leave all the other files in ASCII mode. Even the main
WndProc was left in an ASCII mode file. And it all seems to be working
perfectly.
Now I might have done the same thing by explicitly calling out all the Unicode
versions of Win32 API functions, like RegisterClassW and CreateWindowW. But
that was too prone to error. This way it is all automatic. Having one little
file where UNICODE is defined ensured that these functions will play together
properly.
So to those who say that the only way to do Unicode is to set Unicode for the
entire application, I can now say that it is not necessary.
Robert Scott
Ypsilanti, Michigan