tool tips disappear and will not return

[Pete Gontier]

The single tool tip I've created seems to behave as described in the Platform SDK documentation, except that when its autopop timer goes off (and the tip thus disappears), and I move the mouse outside the tool and then back inside, the tool tip will not reappear. Is this standard behavior?

Apps which have this behavior:

• Internet Explorer 6
• Outlook Express 6
• Windows Media Player 10
  

Apps which do not have this behavior:

• Visual Studio 2003
• Excel 2003
• WordPad (XP SP2)
• Paint (XP SP2)
  

And of course there is a set of apps which do not support autopop at all. I’m guessing they are either incorrectly implementing their own tool tip logic from scratch or incorrectly cherry-picking or synthesizing the messages they forward.

My tool is a window and I've told the tool tip to subclass the window. Not sure if this makes a difference for this particular issue. My application also sub-classes the tool window in order to monitor such things as TTN_SHOW. My sub-classing code has shipped in many products without known issues.

[John Carson]

"Pete Gontier" <kokor...@discussions.microsoft.com> wrote in message
news:C0DD4576.1C4CE%kokor...@discussions.microsoft.com

> The single tool tip I've created seems to behave as described in the
> Platform SDK documentation, except that when its autopop timer goes
> off (and the tip thus disappears), and I move the mouse outside the
> tool and then back inside, the tool tip will not reappear. Is this
> standard behavior?
>
> Apps which have this behavior:
>

> * Internet Explorer 6
> * Outlook Express 6
> * Windows Media Player 10

>
> Apps which do not have this behavior:
>

> * Visual Studio 2003
> * Excel 2003
> * WordPad (XP SP2)
> * Paint (XP SP2)

>
> And of course there is a set of apps which do not support autopop at

> all. I雋 guessing they are either incorrectly implementing their own

> tool tip logic from scratch or incorrectly cherry-picking or
> synthesizing the messages they forward.
>
> My tool is a window and I've told the tool tip to subclass the
> window. Not sure if this makes a difference for this particular
> issue. My application also sub-classes the tool window in order to
> monitor such things as TTN_SHOW. My sub-classing code has shipped in
> many products without known issues.

My tooltips do reappear. The code I use is given below. Note that ttUpdate
is an array of structs containing various initialization data such as the
tooltips text.

HWND hwndTT = CreateWindowEx(WS_EX_TOPMOST, TOOLTIPS_CLASS, NULL,
TTS_NOPREFIX | TTS_ALWAYSTIP,
CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT,
hwndParent, NULL, hInstance,
NULL);
SendMessage(hwndTT, TTM_ACTIVATE, TRUE, 0);

TOOLINFO ti={0};
ti.cbSize = sizeof(TOOLINFO);
ti.hwnd = hwndToolbar;
ti.hinst = hInstance;
ti.uFlags = TTF_SUBCLASS;

for (i=0; i<buttonCount; ++i)
{
RECT rect;
SendMessage(hwndToolbar, TB_GETITEMRECT, i, (LPARAM)&rect);
ti.rect = rect;
ti.uId = ttUpdate[i].idCommand;
ti.lpszText = (TCHAR *) ttUpdate[i].text;
SendMessage(hwndTT, TTM_ADDTOOL,
0, (LPARAM) (LPTOOLINFO) &ti);
}

--
John Carson

[Pete Gontier]

I was able to experiment with what seemed to be the relevant differences between John’s code and my code. Switching away from TTF_IDISHWND was the trickiest part. None of the experiments made a functional difference. I suppose it’s possible that the code differences in concert would result in a functional difference, but I suspect something else is at fault. I wish I could post mine, but it’s part of a class library and it would be difficult to understand outside that context even if I were allowed to do such a thing.

The documentation says tips are shown as the result of WM_MOUSEMOVE messages. I verified that the parent window receives these messages after the tip has popped.

I’ve logged all the notification messages received by the parent window and TTN_POP seems to be the last. Once this notification occurs, no more occur.  I guess this is no surprise because a notification would occur only if the tooltip decided to do something.

I’ve enumerated and logged all the tools (in fact the only tool) on every WM_MOUSEMOVE message and I see no changes over the life of the program, including after TTN_POP.

I’ve noticed it doesn’t seem to matter whether I send TTM_ACTIVATE to the tip window. Does that ring any bells for anyone?

The tool window is embedded deeply within an MDI window. Does that ring any bells for anyone?

---

On 7/14/06 11:05 PM, in article OU0CAT9p...@TK2MSFTNGP04.phx.gbl, "John Carson" <jcarson_n...@netspace.net.au> wrote:

My tooltips do reappear. The code I use is given below. Note that ttUpdate
is an array of structs containing various initialization data such as the
tooltips text.

     HWND hwndTT = CreateWindowEx(WS_EX_TOPMOST, TOOLTIPS_CLASS, NULL,
                            TTS_NOPREFIX | TTS_ALWAYSTIP,
                            CW_USEDEFAULT, CW_USEDEFAULT,
                            CW_USEDEFAULT, CW_USEDEFAULT,
                            hwndParent, NULL, hInstance,
                            NULL);
     SendMessage(hwndTT, TTM_ACTIVATE, TRUE, 0);

     TOOLINFO ti={0};
     ti.cbSize = sizeof(TOOLINFO);
     ti.hwnd = hwndToolbar;
     ti.hinst = hInstance;
     ti.uFlags = TTF_SUBCLASS;

     for (i=0; i<buttonCount; ++i)
     {
          RECT rect;
          SendMessage(hwndToolbar, TB_GETITEMRECT, i, (LPARAM)&rect);
          ti.rect = rect;
          ti.uId = ttUpdate[i].idCommand;
          ti.lpszText = (TCHAR *) ttUpdate[i].text;
          SendMessage(hwndTT, TTM_ADDTOOL, 0, (LPARAM) (LPTOOLINFO) &ti);
     }