Win32 ToolTip disappears never to re-appear with Commctl 6

Question

I'm creating a ToolTip window and adding tools to it using the flags TTF_IDISHWND | TTF_SUBCLASS. (c++, win32)

I have a manifest file such that my program uses the new WindowsXP themes (comctrl32 version 6).

When I hover over a registered tool, the tip appears.
Good.
When I click the mouse, the tip disappears.
Ok.
However, moving away from the tool and back again does not make the tip re-appear. I need to hover over a different tool and then come back to my tool to get the tip to come back.

When I remove my manifest file (to use the older non-XP comctrl32), the problem goes away.

After doing some experimentation, I discovered the following differences between ToolTips in Comctl32 version 5 (old) and Comctl32 version 6 (new):

• New TTF_TRANSPARENT ToolTips (when used In-Place) actually return HTCLIENT from WM_NCITTEST if a mouse button is down, thus getting WM_LBUTTONDOWN and stealing focus for a moment before vanishing. This causes the application's border to flash.

• Old TTF_TRANSPARENT ToolTips always return HTTRANSPARENT from WM_NCHITTEST, and thus never get WM_LBUTTONDOWN themselves and never steal focus. (This seems to be just aesthetic, but may impact the next point...)

• New ToolTips seem not to get WM_TIMER events after a mouse-click, and only resume getting (a bunch of) timer events after being de-activated and re-activated. Thus, they do not re-display their tip window after a mouse click and release.

• Old ToolTips get a WM_TIMER message as soon as the mouse is moved again after click/release, so they are ready to re-display their tip.

Thus, as a comctl32 workaround, I had to:

• subclass the TOOLTIPS_CLASS window and always return HTTRANSPARENT from WM_NCHITTEST if the tool asked for transparency.

• avoid using TTF_SUBCLASS and rather process the mouse messages myself so I could de-activate/re-activate upon receiving WM_xBUTTONUP.

I assume that the change in internal behavior was to accommodate the new "clickable" features in ToolTips like hyperlinks, but the hover behavior appears to be thus broken.

Does anyone know of a better solution than my subclass workaround? Am I missing some other point?

Answer 1

I don't know, but this sounds like a really "hard" problem (in the sense that all real-world) problems are really hard. I bet the underlying problem is something to do with the setting of the focus. Windows that manually do that are evil and generally suffer from all manner of bugs.

Answer 2

You're not the only one who has hit compatablity issues with tooltips between these DLLS.

I too have had nothing but trouble with the new tooltips in the themable common controls. We have already been monkeying with mouse messages and active/deactivating the tips before adding the manifest and theming our application - so it sounds like what your doing isn't too crazy.

We're still living with problems with TTN_NEEDTEXT messages being send constantly as the mouse moves (not just when hovering), positioning problems with large tips (maybe not something new), and odd unicode messages being sent instead of the ANSI versions (which I plan to post as a question at some point).

I've been working on a small scratch program on the side trying to come up with a more stable tooltip system. One where I handle showing (including detecting the hover) and hiding the tip. I could post some of the code if you care to see it.