What is the correct size of tooltip TOOLINFO?

[Tony]

I have the case where TTM_* messages sent to tooltip control simply
don't work.

I got TTM_ADDTOOL to work (return 1 insyead of 0) by making the size
stored in cb field of TOOLINFO 4 bytes smaller, following the
suggestion from one post in device drivers group (sic!).

However, removing the tool still doesn't work (tool count is the same
before and after the call to remove tool) and neither does
GetToolInfo() for a given tool id.

Basically, I am splitting the client rectangle of my window in many
rectangles, each of which is for one tool. I am trying to change
existing tool's rectangle.

The idea was to use GetToolInfo() to find out if I have already added
the tool with a given id and, if yes, I would just change tool's
rectangle. If not, I would call TTM_ADDTOOL to add a tool having given
rectangle for the first time.

When that wouldn't work I tried always deleting a tool before adding
it. But that doesn't work either.

I am running on XP with Common Controls manifest in resources.

I am using Win32 API and most of the code is exactly like in MSDN
examples so I am not listing it.

How is it possible that such a basic piece of functionality, involving
direct calls to SendMessage(toolhwnd, TTM_.., 0, &toolinfo) doesn't
work after all these years?

[Ivo]

The correct size is 44 bytes for Win 2000 and Win XP without common controls 6.0, and 48 bytes for XP with common controls 6.0. If you use the wrong size some of the tooltip messages don't work, while others do.

If you think your size is correct, verify which version of the common controls you are running:

int SIZE_TOOLINFO;
ULONG COMCTL_VERSION=0;
HMODULE dll=GetModuleHandle(_T("comctl32.dll"));
if (dll) {
DLLGETVERSIONPROC DllGetVersion=(DLLGETVERSIONPROC)GetProcAddress(dll,"DllGetVersion");
if (DllGetVersion) {
DLLVERSIONINFO vinfo;
memset(&vinfo,0,sizeof(vinfo));
vinfo.cbSize=sizeof(vinfo);
DllGetVersion(&vinfo);
COMCTL_VERSION=MAKEVERSION(vinfo.dwMajorVersion,vinfo.dwMinorVersion);
}
}

if (COMCTL_VERSION>=MAKEVERSION(6,0)) {
// common controls version 6 (WinXP with visual styles)
SIZE_TOOLINFO=sizeof(TOOLINFO);
}
else {
// Win2000 or XP without visual styles
#ifdef UNICODE
SIZE_TOOLINFO=TTTOOLINFOW_V2_SIZE;
#else
SIZE_TOOLINFO=TTTOOLINFOA_V2_SIZE;
#endif
}

If the size and version seem correct, then it's most likely a bug in your code. A bug in the common controls is not out of the question either, although much less likely.

Ivo

"Tony" <ton...@gmail.com> wrote in message news:1129337093....@g44g2000cwa.googlegroups.com...

[James Brown]

Post the code you think is incorrect.

The following works on all versions of Windows:

TOOLINFO ti = { sizeof(ti) };

// fill in other members
ti.uFlags = ....

James

--
www.catch22.net
Free win32 software, sourcecode and tutorials

"Tony" <ton...@gmail.com> wrote in message
news:1129337093....@g44g2000cwa.googlegroups.com...

[Tony]

I have common controls version 5.82 and, quite simply, without
definitions given by Ivo above, I haven't found a single
SendMessage(hwnd, TTM_...) that works.
For example:

TOOLINFO ti;
memset(&ti, 0, sizeof ti);
ti.cbSize=sizeof(TOOLINFO);
ti.hwnd=my_hwnd;
ti.uId=id;

LRESULT lr=SendMessage(hwndtooltip, TTM_ADDTOOL, 0,
&ti);

returns lr=0. TTM_GETTOOLCOUNT returns nonsense (like 854634454) when
called after adding a tool.

[Tony]

Thanks Ivo! That worked just fine. The only thing I don't understand
now is that I have visual styles active in my app (manifest is embedded
in resources) but DllGetVersion returns 5 for major and 82 for minor
version. All my controls are displayed using active theme and theme
handle is not NULL if I OpenTheme on control's hwnd.

[James Brown]

are you definitely using the latest platform-sdk to compile
your project?

If the answer is "yes", ten this sounds like a bug in a
particular version of common-controls (5.82) - I wonder if any
Microsoft representative could comment?

James

--
www.catch22.net
Free win32 software, sourcecode and tutorials

"Tony" <ton...@gmail.com> wrote in message

news:1129557909....@g47g2000cwa.googlegroups.com...

[Ivo]

There is a bug in the platform SDK documentation. The definition of TOOLINFO differs between the headers and the docs. The actual TOOLINFO structure has an additional undocumented DWORD only used by common controls 6.0.

So just by looking at the docs you'd think you can use the same size all for all versions after 4.70, but that's misleading. The correct sizes are TTTOOLINFOA_V2_SIZE or TTTOOLINFOW_V2_SIZE for 5.82 and sizeof(TOOLINFO) for 6.0.

"James Brown" <dont_bother> wrote in message news:nfednbqS45_...@pipex.net...

[James Brown]

ok....I accept what you're saying. But, alot of the Windows API are
designed to handle structures of varying sizes (i.e. different (newer)
versions
of the same struct. The version of the structure is implicitly stated by the
cbSize member which is commonly set at the start of this type of structure

So, you should always set the sizeof(TOOLINFO) to the size of the
structure that you are seeing in your platform SDK headers. Even if this
structure is different
to what is documented in MSDN (and sometimes it is as there are often
"undocumented" members if you dig into the headers), you *always*
set structname.cbSize = sizeof(structname).

If you compiled you program 4 years ago with the appropriate Platform SDK
at that time, sizeof(TOOLINFO) would have been a specific size.
When you run that same program today,
Windows will be making the decision "this TOOLINFO's cbSize member
is set to an old value, I will assume that this is an older version of the
TOOLINFO
structure from an old program, and I will not inspect the new TOOLINFO
members
that were introduced recently... because they don't exist in this "old"
TOOLINFO struct.

Windows has always been backward compatible by design, and I still think
this
is an error in the common-controls library..you can work around it, but it
ain't right (imho!!).

James

--
www.catch22.net
Free win32 software, sourcecode and tutorials

"Ivo" <ivo> wrote in message news:jLqdneHkId8...@adelphia.com...

[Tony]

James Brown wrote:
> Windows has always been backward compatible by design, and I still think
> this is an error in the common-controls library..you can work around it, but > it ain't right (imho!!).

You are right! I have been programming Windows since v 2.11 days and
these kinds of problems do happen rarely. In 99% of cases Windows code
expects and works around changing structure sizes. I guess they got a
bunch of younger programmers who simply don't understand what does all
that prehistoric stuff with structure size really mean.

That is precisely why I posted here (I visit ms.public NGs once in a
year, if even that often) after I discovered a finding similar to Ivo's
in NG for device drivers ... and no other mention of it anywhere else,
on the whole Great Google!!! Clearly, you can forget about MSDN KB,
assuming you manage to find anything in MSDN Library with its umptienth
variation on user interface.

It sure feels lonely (apparently) being among the few programmers who
used tooltips in 5.82 version of commctrl32.dll in the last 3 years.

[Ivo]

Yes, I used to think this way too... Until I stumbled onto a problem with the tooltips myself.
Here's Raymond Chen's thoughts on the subject:
http://blogs.msdn.com/oldnewthing/archive/2003/12/12/56061.aspx

In theory it is possible for newer OS to recognize older struct sizes and emulate the old behavior. I haven't tried it myself with the tooltips. It is possible that it won't work in this case however. If you do have a manifest XP thinks that you know about common controls 6.0, and you will use all the new sizes. If you don't have a manifest it runs the old 5.82 code, which will not work with the new sizes.

Truth be told, I haven't experienced such problems with other controls besides the tooltips. Maybe their code is just more tolerant, or they haven't changed that much.