<p>I'm creating a <a href="http://msdn.microsoft.com/en-us/library/bb760250&#40;VS.85&#41;.aspx" rel="noreferrer">ToolTip</a> window and adding tools to it using the flags
TTF_IDISHWND | TTF_SUBCLASS. (c++, win32)</p>

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

<p>When I hover over a registered tool, the tip appears.<br>
Good.<br>
When I click the mouse, the tip disappears.<br>
Ok.<br>
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.</p>

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

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

<ul>
<li><p>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.</p></li>
<li><p>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...)</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ul>

<p>Thus, as a comctl32 workaround, I had to:</p>

<ul>
<li><p>subclass the TOOLTIPS_CLASS window and always return HTTRANSPARENT from
WM_NCHITTEST if the tool asked for transparency.</p></li>
<li><p>avoid using TTF_SUBCLASS and rather process the mouse messages myself so
I could de-activate/re-activate upon receiving WM_xBUTTONUP.</p></li>
</ul>

<p>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.</p>

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

[{'answer_id': 51340, 'author': '1800 INFORMATION', 'author_id': 3146, 'author_profile': 'https://Stackoverflow.com/users/3146', 'pm_score': 0, 'selected': False, 'text': '<p>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.</p>\n'}, {'answer_id': 51857, 'author': 'Aardvark', 'author_id': 3655, 'author_profile': 'https://Stackoverflow.com/users/3655', 'pm_score': 1, 'selected': False, 'text': "<p>You're not the only one who has hit compatablity issues with tooltips between these DLLS. </p>\n\n<p>I too have had <strong>nothing but trouble</strong> 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.</p>\n\n<p>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).</p>\n"}]
['https://Stackoverflow.com/questions/51146', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/5309/']