ToolTips

This can be both MFC or API.
How can I assign a tool tip control to something that's not a control. Like in VC++, when you move the mouse over a variable, it shoes you the declaration. I want to do something similar.

Thx in advance

From MSDN:

Code:

---

HWND WINAPI CreateTT(HWND hwndOwner)
{
    INITCOMMONCONTROLSEX icex;
    HWND        hwndTT;
    TOOLINFO    ti;

    // Load the ToolTip class from the DLL.
    icex.dwSize = sizeof(icex);
    icex.dwICC  = ICC_BAR_CLASSES;

    if(!InitCommonControlsEx(&icex))
      return NULL;

    // Create the ToolTip control.
    hwndTT = CreateWindow(TOOLTIPS_CLASS, TEXT(""),
                          WS_POPUP,
                          CW_USEDEFAULT, CW_USEDEFAULT,
                          CW_USEDEFAULT, CW_USEDEFAULT,
                          NULL, (HMENU)NULL, g_hinst,
                          NULL);

    // Prepare TOOLINFO structure for use as tracking ToolTip.
    ti.cbSize = sizeof(TOOLINFO);
    ti.uFlags = TTF_IDISHWND | TTF_TRACK | TTF_ABSOLUTE;
    ti.hwnd  = hwndOwner;
    ti.uId    = (UINT)g_hwndMain;
    ti.hinst  = g_hinst;
    ti.lpszText  = LPSTR_TEXTCALLBACK;
    ti.rect.left = ti.rect.top = ti.rect.bottom = ti.rect.right = 0;
   
    // Add the tool to the control, displaying an error if needed.
    if(!SendMessage(hwndTT,TTM_ADDTOOL,0,(LPARAM)&ti)){
        MessageBox(hwndOwner,"Couldn't create the ToolTip control.",
                  "Error",MB_OK);
        return NULL;
    }
   
    // Activate (display) the tracking ToolTip. Then, set a global
    // flag value to indicate that the ToolTip is active, so other
    // functions can check to see if it's visible.
    SendMessage(hwndTT,TTM_TRACKACTIVATE,(WPARAM)TRUE,(LPARAM)&ti);
    g_bIsVisible = TRUE;

    return(hwndTT);   
}

---

Look under Common Controls and then ToolTips :)

Thx, I think I'll be able to translate that to MFC. Took me kinda long to find the article you mentioned, though.

Any particular reason for using MFC? :p

I think there might be a class in there somewhere.

There is a class, but it is specialized in using tool tips for buttons and such. It's a little bit complicated to do otherwise.
The reason why I use MFC is that I don't know anything about MDI programming in API (skipped that chapter in the Petzold and forgot to read it later), and MFC makes that easy. Speed is not an issue in my app (mostly text processing), so there is no reason not to use MFC.

Speed isn't the problem I have with it, it's size :)

Anyway if you want MDI then I suppose I can let you off :p

About the size of a MFC app...
Nearly all the code is in the MFC40.dll (or something like this), so I don't think it does increase the size all that much. The dll is loaded anyway when you start VC++ for example. Actually this is the reason why there are shared libraries. The ASSERT family of macros disappears in release versions. The masses of inline functions aren't bigger than the normal API calls.
Just my thoughts however.

Yes, but then you need to distribute MFC42.DLL as well. You can statically link it, but then your app gets to about 3 times the size.

I think the dll is installed with windows. And it's usually no problem to distribute the dll, I haven't yet heard of a program that lacks space on it's CD-ROM. On the end-user side... as I said, I think it's already installed, therefor takes up no space.

I think if you were to learn VC++, learning in MFC is a wate of time. but learning Win32 Application is rather better:)

Yeah, but I know VC++ already, and I want to save time.

It's the principle of the thing :p

You cannot guarantee it will be installed. And what if you're distributing over the internet? Are people going to want to download an extra 1.5mb for a 10K program? You need a proper setup as well since it needs its shared-file count incremented as well if necessary.

Ok, you got me beat. I won't distribute my MFC-programs over the internet.

;)

MFC is okay in certain situations. For example, if you need the Document/View paradigm, and your program is large enough that it might conceivable use a large proportion of the library, then it's not too bad. But for most things it's easier just to ignore it and write the code :)

It's like VB is okay if you're doing a database app :D