Mixed tooltips using AddTool (GetDlgItem (IDC_THIS), IDC_THIS) and AddTool (this, LPSTR_TEXTCALLBACK) how to.

         m_tooltip.AddTool(GetDlgItem(IDC_LIST1), LPSTR_TEXTCALLBACK);
instead of
          m_tooltip.AddTool (this); // or AddTool (this, LPSTR_TEXTCALLBACK, cr, IDC_THIS)
make it work for enabled control. I used the other version hoping that I can that way circumvent the disabled button/control. It seems that I need to convince the disabled button to display tooltips instead.

Sorry - I hadn't read your requirement completely.  It seems that a disabled control doesn't have a tooltip.
This may not work.  Display a tooltip based on a rectangular area in the dialog the control is on.  (Show/Hide by code - update and pop functions).
I'll have to look it up here, I seem to recall reading about this some time ago

BOOL AddTool( CWnd* pWnd, LPCTSTR lpszText = LPSTR_TEXTCALLBACK, LPCRECT lpRectTool = NULL, UINT nIDTool = 0 );

Return Value

Nonzero if successful; otherwise 0.

Parameters

pWnd

Pointer to the window that contains the tool.

nIDText

ID of the string resource that contains the text for the tool.

lpRectTool

Pointer to aRECT structure containing coordinates of the tool’s bounding rectangle. The coordinates are relative to the upper-left corner of the client area of the window identified by pWnd.



this seems to imply using the dialog itself and supplying a rect ought to work

instead of
m_tooltip.Create(this, TTS_NOPREFIX);

try
m_tooltip.Create(this, TTS_NOPREFIX | TTS_ALLWAYSTIP);

Now I tried using:
          m_tooltip.Create(this, TTS_ALWAYSTIP);
          m_tooltip.SetDelayTime(TTDT_AUTOPOP, 10000);     //display for 10 seconds (stop flashing)
and if I activate the tooltip with another not disabled control I can see the message flashing. Sometimes for a time long enough to read the text because I know what its content is. But not really nice.

At least now I know that the TTN_NEEDTEXT handler is called.
Problems I was facing is that for static controls only the way you described in the last posting works and for controls like buttons it doesn't seem to work. Is this just me? Or is it a feature of MFC.

New test with TTS_ALWAYSTIP in call and two buttons added like
        CRect cr;
        c_cbMeasureChip.GetWindowRect (cr);
        ScreenToClient (cr);
        ftooltip.AddTool (this, LPSTR_TEXTCALLBACK, cr, IDC_BT_MEASURE_CHIP);
        ftooltip.AddTool (GetDlgItem(IDC_BT_TEST_CHIP), LPSTR_TEXTCALLBACK);

For either button I can see the tooltip flash for less than a second and disappear right after, sometimes reappearing again.

http://www.codeguru.com/Cpp/controls/controls/tooltipcontrols/article.php/c2277/
describes how to enable tooltips for disabled controls changing the HWND from the dlg ones to the controls. Perhaps I need to implement this. In the TTN_NEEDTEXT handler the HWND is that of the control.

I've just tried the TTS_ALWAYSTIP on a disabled (text callback) control and despite help says it doesn't display the tip!

You should be able to use the rectangle approach (needs unique number for each rectangular area).  Instead of passing the ID of the control to attatch the tip to you pass a bounding rectangle and an ID number.  If I understand that correctly it isn't checking if it is on a control - it checks if it is in the rectangle.

something like
CRect rect;
GetDlgItem(IDC_X)->GetWindowRect(&rect);
ScreenToClient(&rect);
AddTool(this, LPSTR_TEXTCALLBACK, &rect, 1);
GetDlgItem(IDC_Y)->GetWindowRect(&rect);
ScreenToClient(&rect);
AddTool(this, LPSTR_TEXTCALLBACK, &rect, 2);

Now I tried changing the adding in OnInitDialog to
        ftooltip.AddTool (this, LPSTR_TEXTCALLBACK, cr, 1);
        ftooltip.AddTool (this, LPSTR_TEXTCALLBACK, cr, 5000);
        ftooltip.AddTool (&c_cbMeasureChip, LPSTR_TEXTCALLBACK, cr, 5000);
no success. TTN_NEEDTEXT handler gets only called sometimes. Why this?

        ftooltip.AddTool (GetDlgItem(IDC_BT_TEST_CHIP), LPSTR_TEXTCALLBACK);
Works better but the tooltip flashes for only a very short time. No one will be able to read this.

The help is even more inconsistent. For the callback case it states that

lpszText

Pointer to the text for the tool. If this parameter contains the value LPSTR_TEXTCALLBACK, TTN_NEEDTEXT notification messages go to the parent of the window that pWnd points to.

Since I suppply this to pWnd the parent of the dialog should get the TTN_NEEDTEXT message.

How I understand the tooltip now it seems that the (disabled) control over the main dialog will prevent the main dialog handling the tooltip. But what stuns me is that I tried to move the cr(CRect) to be above the control but still

Looking more carefully at your code I discovered that you use address to CRect structures whereas I used the CRect objects. Why doesn't my version fail?

ulp?  argle! out of cheese error. Please re-install the universe. grnch. boiiing.

I don't have any more time at present.  Maybe this evening I can look at this.


<What happens if you supply a text string, ignore the callback at present - try to simplify the problem>

Using the rectangle approach I can get callback text for a disabled control.  
In the callback function the following line needs to be removed
   if (pTTT->uFlags & TTF_IDISHWND)
as it is not using a window as the ID.

Using the TTS_ALWAYSTIP fails on a disabled control both for callback and static tips text.

The callback is a bit less demanding. This I got for some of the disabled controls but not always! Only having got a text set no tooltip is displayed or for a too short time to be visible.

But I think I discovered a part of the problem which I did not wrote here yet. This dialog is a subdialog of the main one. Sometimes this resulted in the message TTN_NEEDTEXT to be sent to the main dialog which did not handle this message. In there I can see that
HWND ctl = (HWND)pNMHDR->idFrom;
is the handle of the subdialog with the corresponding control.

Since I had problems adding tools of subdialogs to the main dialog I added a tooltip control to each subdialog responsible for its tools. For all enabled controls this works OK. Only for the disabled ones the messages seem to get lost in the hierachy. The TTN_NEEDTEXT doesn't seem to get always posted to the parent window of the first parameter in AddTool. Sometimes they arrive at the window itself and sometime at its parent. Is there any known algorithm to decide which gets the message on what conditions.

The line
    if (pTTT->uFlags & TTF_IDISHWND)
is needed but in a different context:

    UINT id;
    if (pTTT->uFlags & TTF_IDISHWND)
    {
          id = ::GetDlgCtrlID((HWND)nID;
    }
    else {
          id = nID;
    }

For static controls not the HWND is idFrom but the control ID itself. Hope this gets me closer to my goal.

2nd comment - good.
1st comment - I don't understand why it is failing with the alwaystip setting.  Algorithm - that would be in the commoncontrol implementation itself.  Maybe this is another of the rich selection of features available in windows.

Snippet from
http://www.codeguru.com/Cpp/controls/controls/tooltipcontrols/article.php/c2277

// This function is a patch that overcomes MFC bug of
// tooltips that don't show up on in disabled controls
// if modal dialogs. Call this function in your overidable of
// PreTranslateMessage, before calling the inherited one.

A solution I found (or better a work around) is putting a static control underneath the buttons.

Inactive buttons let the tooltips display by the hidden static underneath using
        c_cbPlaceChip.GetWindowRect (&cr);
        ScreenToClient (&cr);
        ftooltip.AddTool (this, LPSTR_TEXTCALLBACK, &cr, IDC_STATIC_PLACECHIP);
The last parameter is the value which gets passed to the TTN_NEEDTEXT handler. I can choose anything different from 0 and -1 but using the value of the string resource = control ID is the easiest.

tips for active buttons are still handled via them:
        ftooltip.AddTool (GetDlgItem(IDC_BT_PLACECHIP), IDC_BT_PLACECHIP);

Thx for your help. Since I did part of the work for the solution myself I grade it as B.

A solution I found (or better a work around) is putting a static control underneath the buttons.


As long as it works.  It ought to be possible to accomplish exactly this with the rectangle method, you could always pass the hwnd of the real control as the numeric ID.  That would use less handles as you aren't having to have as many controls.  It would also make mods to the dialog easier (resize/move only one control).

Will try if this is achievable. Perhaps with a ID different from a control?

I did it here last night, disabled a control, tested - no tip, got the window rect, convert to client added tip for rect, it worked.

Do you have more controls on it?

I tried the same approach as well but to no avail. The button if not added as tool is eating the mouse move messages so the rect/static doesn't get its turn. Do you have some code were this is working?

On www.flounder.com there is a validating edit control with a disabled button which explains why it is disabled. But there the dialog seems to handle all tooltip messages since there is only one control.

It was a list box on a dialog.  When disabled the rect approach worked, when enabled then having it as a control worked.  (both callback - the code I initially posted was for displaying different tips depending on the line in the list the mouse was on.)

Ok, so the difference to my approach was that I put a static underneath. Using just the rectangle of the button works OK in my case as well. I just needed to make sure that they are not both wired to the same tool ID (the buttons control ID). But you are right, having to move/resize an additional control on the panel makes it more difficult. A simple string resource for the rectangle is sufficient and more efficient.

So thanks again.