[RESOLVED] YA disabled control tooltip issue

I know the topic of tooltips not showing for disabled controls is very "mature", and I'm reluctant to ask, but after looking at 100's of search hits, on this forum, MSDN, and others, I'm stuck.

I see there are some workarounds for MFC and WinForms and other programming styles that I don't use, but for Win32 API code, nothing found. I basically understand why this happens (disabled controls don't get messages), but my experiments are all failures. I'm using VC8 IDE.

For example, handling the dialog WM_MOUSEMOVE, checking ChildWindowFromPoint(), if disabled control then SendMessage(hWtip, TTM_RELAYEVENT, ...). I don't understand why this doesn't work. I'm ready to believe the older Win32 TOOLTIPS_CLASS windowproc must check the state of the control and ignore disabled ones.

I hope someone can point me in the right direction. I mean something more specific than "check the CodeGuru controls section", which is a dead end (for API solution). Help, I'm dying here :( .

Did you try to handle TTN_NEEDTEXT notification in the dialog?

Quote:

---

Originally Posted by cosmicvoid

For example, handling the dialog WM_MOUSEMOVE, checking ChildWindowFromPoint(), if disabled control then SendMessage(hWtip, TTM_RELAYEVENT, ...). I don't understand why this doesn't work.

---

You seem asking about internal Windows details never documented officially.

Quote:

---

I see there are some workarounds for MFC ...

---

Please don't rumor on this. :) MFC uses standard Win32 TOOLTIPS_CLASS controls and handles those in full accordance with MSDN. So you either run through MFC sources to see what happens under the hood, or post your project here to let people suggest on your problem.

Quote:

---

Originally Posted by VictorN

Did you try to handle TTN_NEEDTEXT notification in the dialog?

---

Victor, I did not consider the TTN_NEEDTEXT notification, because the tip text is already known to the tooltip when the control is added with the TTM_ADDTOOL message. All the non-disabled controls will show a tip with no problem.

Quote:

---

Originally Posted by Igor Vartanov

You seem asking about internal Windows details never documented officially.

---

I think WM_MOUSEMOVE, ChildWindowFromPoint(), TTM_RELAYEVENT are documented. I think the internals of the tooltip class proc are the mystery, so there is no way to know why my experiments are failing.

Quote:

---

Please don't rumor on this. :) MFC uses standard Win32 TOOLTIPS_CLASS controls and handles those in full accordance with MSDN. So you either run through MFC sources to see what happens under the hood, or post your project here to let people suggest on your problem.

---

Rumor? I am not sure what programming style is used in the 'workarounds' that I saw (maybe not actually MFC, maybe .NET). They are using classes/methods that are unfamiliar to me, and there are no sources for these functions/libraries, so I cannot see 'under the hood', much less infer what these class methods are doing.

I can give you some of my code, though.

The tooltip initialization section, in WM_INITDIALOG:

Code:

---

       
        hWtip = CreateWindowEx(NULL, TOOLTIPS_CLASS, NULL, WS_POPUP | TTS_BALLOON,
                                CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,  CW_USEDEFAULT,
                                hWnd, NULL, hInst, NULL);
        if (hWtip)
        {
                SecureZeroMemory(&ti, sizeof(TOOLINFO));
                ti.cbSize = sizeof(TOOLINFO);
                ti.hwnd = hWnd;
                ti.uFlags = TTF_IDISHWND | TTF_SUBCLASS;
                for (c = 0; c < ELEMENTS(TipList); c++)
                {
                        ti.uId = (UINT_PTR)GetDlgItem(hWnd, TipList[c].uID);
                        ti.lpszText = (LPTSTR)TipList[c].tip;
                        SendMessage(hWtip, TTM_ADDTOOL, 0, (LPARAM)&ti);
                }
                SendMessage(hWtip, TTM_SETDELAYTIME, TTDT_INITIAL, 300);
                SendMessage(hWtip, TTM_SETDELAYTIME, TTDT_RESHOW, 0);
                SendMessage(hWtip, TTM_SETDELAYTIME, TTDT_AUTOPOP, 8000);
                SendMessage(hWtip, TTM_SETMAXTIPWIDTH, 0, 400);                // to cause multi line tips
        }

---

The experiment to pass mouse messages for disabled controls to the tooltip proc:

Code:

---

        case WM_MOUSEMOVE:
       
                mouse.x = LOWORD(lParam);
                mouse.y = HIWORD(lParam);
                hWchild = ChildWindowFromPoint(hWnd, mouse);
                if (! hWchild || hWchild == hWnd)
                        break;
                if (hWchild == GetDlgItem(hWnd, IDC_LIST))        // disabled control
                {
                        SendMessage(hWtip, TTM_RELAYEVENT, 0, (LPARAM)(LPMSG)&uMsg);
                }
                break;

---

One other thing I don't understand

Code:

---

                                                // note that 0x0501 causes tooltips to fail in this app
#define _WIN32_WINNT 0x0500        // 0x0500 = W2K, 0x0501 = XP, 0x503 = WS03, 0x0600 = Vista, 0x0601 = W7

---

Tooltips do not work if _WIN32_WINNT is 0x0501. I suspect it is a manifest problem and a wrong dll version. This was an attempt to use TTM_ messages that are only supported in Comctl32.dll version 6.0 (remember I'm using 8 yr old IDE). This is only preventing further experiments, and not directly related to the 'no tip for disabled control' issue.

I don't know if this gives enough info to help with a solution.

Afterthought: If I can figure out how tp put Comctl32.dll version 6.0 into the manifest, then I could experiment using TTM_POPUP as a workaround.

I fixed a bug in my WM_MOUSEMOVE handler, but no matter what I've tried I cant get the TTM_EVENTRELAY message to trigger a tooltip window. I've tried several other pieces of sample code that use the TTM_EVENTRELAY method, but none of them work either. :confused:

So I've given up on the WM_MOUSEMOVE/TTM_EVENTRELAY experiments, and tried the old "phantom control" idea, where another control is in the same location as the "real control", but the phantom control is registered as the tooltip trigger and is never disabled. This works very well, except that I have not found a way to keep the phantom controls underneath (lower in Z order than) the real controls. Trying to use SetWindowPos() to change the Z order of the phantom controls or real controls does not work. At times, the phantom control will obscure the real control, and I don't know why.

Any ideas or advice?

Success with the phantom control method. The key is here:
http://forums.codeguru.com/showthrea...555#post336555

Quote:

---

Originally Posted by cosmicvoid

I think the internals of the tooltip class proc are the mystery, so there is no way to know why my experiments are failing.

---

The internals were precisely what I told you about. It is not documented what to happen when you add a tooltip with TTS_SUBCLASS and then you spam your tooltip window with relayed events for the same control.

Quote:

---

Originally Posted by cosmicvoid

Rumor? I am not sure what programming style is used in the 'workarounds' that I saw (maybe not actually MFC, maybe .NET).

---

Yeah, this is what I call rumoring. :)

Quote:

---

Originally Posted by cosmicvoid

They are using classes/methods that are unfamiliar to me, and there are no sources for these functions/libraries, so I cannot see 'under the hood', much less infer what these class methods are doing.

---

MS includes MFC source codes into VS bundle starting from the very ancient versions. So you can see under the hood of MFC, anytime.

Quote:

---

Originally Posted by cosmicvoid

I can give you some of my code, though.

---

Thanks, but I expected something compilable to do my experiments on. Like the sample I attach here. ;)

Please note, there are no phantom controls or something. And it's not a 'workaround', just a design approach to meet your requirement "tooltip showing over disabled control"

Attachment 32299

Code:

---

    case WM_INITDIALOG:
        {
            hTip = CreateToolTip(hDlg);
            BOOL
            res = AddTool(hTip,GetDlgItem(hDlg,IDOK),NULL,0,"OK button");
            res = AddTool(hTip,GetDlgItem(hDlg,IDCANCEL),NULL,1,"Cancel button");

            // add just an area for demo
            RECT r = {0, 0, 100, 25};
            res = AddTool(hTip,hDlg,&r,2,"Dialog");

            // add area right under Cancel button
            GetWindowRect(GetDlgItem(hDlg,IDCANCEL), &r);
            ScreenToClient(hDlg, (LPPOINT)&r);
            ScreenToClient(hDlg, ((LPPOINT)&r) + 1);
            res = AddTool(hTip,hDlg,&r,3,"Cancel button (disabled)");

            EnableToolTip(hTip,TRUE);
            CheckDlgButton(hDlg, IDC_ENABLE, TRUE);
        }
        break;

---

The design is based on the fact that disabled control does not capture mouse events, so those are passed directly to parent that has another tool area registered with the same on-screen position.

Igor,
I decided not to go into a long windy reply to your points, and I'm sorry that I didn't realize you were expecting a compilable sample. And thanks for your sample, I will experiment with it if I do further changes to my program.

Early in my experiments, I tried the method you show, using a RECT area instead of a control, but it did not work for me; I suppose my code has bugs I'm not aware of.

Quote:

---

Originally Posted by Igor Vartanov

...snip... Please note, there are no phantom controls or something. And it's not a 'workaround', just a design approach to meet your requirement "tooltip showing over disabled control" ... The design is based on the fact that disabled control does not capture mouse events, so those are passed directly to parent that has another tool area registered with the same on-screen position.

---

To me, this sounds pretty much the same idea as the "phantom control".

Please always consider posting your problem in a form of compilable project having your code be focusing on the problem as much as possible. Especially this is applicable to GUI programming when you have your logic parts scattered, here and there, and due to this you may miss something 'there' when posting code snippets on 'here'.