ToolTip disappears never to re-appear with Commctl 6

[David C]

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.

Can anybody offer any work-arounds to this problem? I noticed that Windows
Explorer doesn't have this issue. Watching messages with Spy++ showed lots of
TTM_POP messages being sent, so I don't know what Explorer is doing. I
examined some other programs with Spy++ and they seem to have different
tactics (constantly disabling and re-enabling tooltips, etc.).

If anyone has any insight into how the internal MS programs do it (Explorer,
ListView controls, etc.) that would be very helpful! Three hours of googling
didn't turn up much.

Thank you!!

[David C]

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

1) 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:

2) 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.

Anyone know why these things are?

Thus, for 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 recieving WM_xBUTTONUP.

Why do ToolTips behave so differently in comclt32 version 6 than they did
before?

Are these things by design?

Thanks,
David C

[Timo Kunze]

David C schrieb:

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

Is the tooltip still working as it should if it contains a link or a
close button?

Timo
--
www.TimoSoft-Software.de - the home of ExplorerTreeView
Stop software patents!

[David C]

Timo,

Good point. I guess that explains #1 above (to a certain extent). Due to the
new mouse-click features, the tip needs to get WM_LBUTTONDOWN in comctl32.
Too bad it couldn't return TRANSPARENT *unless* you had a close box or
hyperlink (which I don't).

However, this still does not address my point #2 above regarding the
suppressed WM_TIMER messages after clicking. I.e. why does a comclt32 version
6 tip never appear again after it is clicked (use Spy++ to see what I mean
about the missing WM_TIMER messages).

Thanks!
Dave