http://tech.groups.yahoo.com/group/wtl/message/16194
Then I created a simple Win32 app with a dialog to test this w/out all
the overhead of the rest of the code in my plugin. The results where
even more confusing - it worked when the app was set to "Use Multi-
Byte Character Set" in the Character Set property, and did NOT work
when made it Unicode!!!! That is a fact, works for ANSII, does not
work with Unicode!!
The reason i'm so confused is that the other plugin mentioned in the
above post (an IE Infoband) is also set to Unicode, so how come that
works???
Not only that, i discovered that if I use sizeof(TTTOOLINFO_V1_SIZE );
as the size of my TOOLINFO structure and not sizeof(TOOLINFO ); then
the call to AddTool( .. ) succeeds, if not it fails.
Can anyone help me figure this out?
As you must know, Unicode means 2-byte characters instead of 1-byte ANSI
or some "unpredictable" number of bytes for MBCS. The core character
type is wchar_t or unsigned short rather than char. This means a lot of
code must be written differently to compile for Unicode. Typically,
people will use the macro types declared in tchar.h. But since you
didn't post any actual code, I don't have a clue what you did wrong.
Soemone else will have to answer about the TOOLINFO question.
The code for the tooltip creation is in the link I added at the
beginning of the post.
I am aware of the differences between UNICODE and ANSI, and throughout
the code I'm using TCHAR's and the _T macro. The problem is not
compiling the code using UNICODE, the problem is I don't understand
why CTooltipCtrl works fine with ANSI compiled code and doesn't on
UNICODE. When stepping into CTooltipCtrl class methods, everything
looks fine - the strings passed in are the correct ones. The tooltip
window just doesn't show up.
Look at the bottom of your StdAfx.H file and I believe you'll see that a
different version of Common Controls is manifested when _UNICODE is
defined. My guess is that this is somehow related to your symptom.
Thanks Scot
I don't have that #ifdef anywhere - but as far as the version of the
ComCtl32 dll used, I added this pragma to make sure i'm using version
6:
#pragma comment(linker, \
"\"/manifestdependency:type='Win32' "\
"name='Microsoft.Windows.Common-Controls' "\
"version='6.0.0.0' "\
"processorArchitecture='*' "\
"publicKeyToken='6595b64144ccf1df' "\
"language='*'\"")
And when I look at my dll with Depends, it does actually show the
right version of ComCtl32.