Download demo project - 18 Kb
Download source files - 2 Kb
Introduction
This sample demonstrates how to show tooltips in modal dialog boxes.
Besides that, it illustrates some basic principles of code reuse and the spirit of MFC programming.
The sample was created using Visual C++ 6.0, but should work from 4.2 on.
How to integrate the sample in your application
How it works
The sample uses the MFC CToolTipCtrl, which is built around a Windows Common Control. This common control does all the work for us.
The only thing to do is create the control, assign tooltips to windows and relay the mouse messages.
The function CToolTipDialog::OnInitDialog() looks up all strings with ID's that match the ID of a control.
BOOL CToolTipDialog::OnInitDialog()
{
BOOL bResult = CDialog::OnInitDialog();
m_wndToolTip.Create(this);
m_wndToolTip.Activate(c_bShowToolTips);
CWnd *pWndChild = GetWindow(GW_CHILD);
CString strToolTip;
while (pWndChild)
{
int nID = pWndChild->GetDlgCtrlID();
if (strToolTip.LoadString(nID))
{
m_wndToolTip.AddTool(pWndChild, strToolTip);
}
pWndChild = pWndChild->GetWindow(GW_HWNDNEXT);
}
return bResult;
}
The standard windows program has a main loop that calls GetMessage(), TranslateMessage() and DispatchMessage() continuously.
The MFC main loop and the modal loops contain some extra's. One of these is calling PreTranslateMessage() before TranslateMessage().
This gives us the chance to peek at every message or to filter messages before they are dispatched.
This is the place where we can intercept all mouse messages and relay them to the tooltip control.
BOOL CToolTipDialog::PreTranslateMessage(MSG *pMsg)
{
if (c_bShowToolTips &&
pMsg->message >= WM_MOUSEFIRST &&
pMsg->message <= WM_MOUSELAST)
{
MSG msg;
::CopyMemory(&msg, pMsg, sizeof(MSG));
HWND hWndParent = ::GetParent(msg.hwnd);
while (hWndParent && hWndParent != m_hWnd)
{
msg.hwnd = hWndParent;
hWndParent = ::GetParent(hWndParent);
}
if (msg.hwnd)
{
ListBoxTextExpand(&msg);
m_wndToolTip.RelayEvent(&msg);
}
}
return CDialog::PreTranslateMessage(pMsg);
}
As pointed out by Richard Collins, it is not enough to just relay the mouse events to the tooltip control. This would not work for controls that have child windows. A combo box for example has an edit control as a child. When a mouse message is sent to this edit control, hWndParent will be the combo box, not the dialog. The message is adjusted to make the tooltip control believe it was actually sent to the combo box. Of course, the original message is passed on to the base class function.
Automatic expansion of listbox strings
Murali Soundararajan added the code to show listbox strings in the tooltip. To do this, you just give your listbox the string TOOLTIPEXPAND. All the rest is done for you. The tooltip will show the text of the listbox item beneath the mouse. This will not work with owner drawn listboxes. This is what the call to ListBoxTextExpand(&msg) is needed for.
Code Reuse
The CodeGuru site already contains an article by Dave Bixler that does just the same.
However, Dave tells us to write the same code over and over again for every dialog.
There are two reasons why you should avoid this:
- My highschool math teacher used to say a mathematician should be as lazy as possible. This goes even more for a programmer. You should always write as few code as possible.
- Chances are you will want to change this code later on. Maybe you'll want to display your tooltips as a marquee in an oval window. At that moment, you will want to change your code at exactly one place.
Extending MFC
This sample only contains a very small piece of code. You might wonder if it is worth the effort of making a general base class and deriving from it.
However, you can put other stuff in this class later on, and all your dialogs will get the new stuff for free.
This is a general principle that should be adhered to. When deriving a class from an MFC class, you should always create a middle class like this one.
Everything that is general goes in the base class, everything that is application specific goes in the derived one.
The result: When you are finished creating an application, you will have your own extension library to MFC. All functionality is there to be used in a new application.
Putting strings in the resource file
This may not be clear to Americans, but Europeans know all about it: you should put all your strings in a resource file. Microsoft has warned us often enough.
Why? Because one day or another, people start asking if they can get a French, German,... version of your software.
It might happen to you to, once your application is starting to get known all over the world.
Making thing go automatically
The spirit of MFC is making things go automatically. All kinds of terrible macros are invented to make the framework usable by wizards and all kinds of resources are loaded without you knowing it.
As an example, tool tips for toolbars ae automatically loaded. This does not always enhance the readability of the MFC source, but it does make life easier for programmers.
When extending MFC (or simply using it), you should follow the same principles.
This is why the resource strings have the same ID as the controls. You should always try to find tricks like this.
It can even sometimes be useful to create new macros that fit in the message maps or other maps.
