Introduction

Recently, I wanted to show a tool-tip to display some information about an object in a diagram. I wanted the tool-tip to contain the name of the object, followed by any comment text about that object. That was fine, except it looked very plain. What I really wanted was to show the object's name in a bold font, and the rest in the normal font, so I came up with the control presented here.

This control is a drop-in replacement for a CToolTipCtrl control, with the added benefit of being able to specify rich-text as the tool-tip text. Information on the rich text format can be found on MSDN.

Using the Demo Application

The demo application demonstrates the rich-tip control using a simple edit control, whose text is added to its tool-tip, and also a rich-edit control, with a few formatting buttons. Text in the rich-edit control appears in the tip for the rich-edit control. Rich-text may be pasted into the rich-edit control from other applications, or alternatively, if there is a file named test.rtf in the EXE's directory, then it is streamed into the control on running the application.

Using the Control

This control should be used in exactly the same way as CToolTipCtrl. While the demo application demonstrates how to add tool-tips to various controls, the basic steps for simple usage are as follows:

Add a CRichToolTipCtrl member variable to the window class which is to have the tool tips, thus:

CRichToolTipCtrl m_tip;

Next, add a call to create the control in your OnInitDialog, if it's a dialog, or your OnInitialUpdate, if it's a view, or in OnCreate for a control or other window:

m_tip.Create(this);

You should then add the following line to your PreTranslateMessage override:

m_tip.RelayEvent(pMsg);

Once that's done, you can start adding tools to the control. So, to add a tool tip to the OK button of a dialog, you would then call, in your OnInitDialog, after creating the tip control:

As with the standard CToolTipCtrl, if you don't specify any text for the tool, then the tool-tip control sends the dialog a TTN_GETDISPINFO/TTN_NEEDTEXT notification. See the code of the demo application for an example of how to handle this.

Implementation Notes

Once I had realised that I was going to write my own control, I had to come up with a way of entering text such that it could be parsed, and displayed. I had a choice:

Devise my own markup, and parse it.

Accept and parse RTF or HTML.

Use a control which parses RTF/HTML, and can output to a given device context.

I didn't really want to do 1 or 2, and I favoured RTF over HTML, as images can be embedded into RTF, so I had a look at the WordPad sources, which uses CRichEditView, to see how it rendered its output to the printer, and found that it uses CRichEditCtrl::FormatRange(), which draws the output to a specified device context.

Having found out how to render the RTF, I added a handler for the NM_CUSTOMDRAW notifications to draw to the tool-tip's window. To prevent the default rendering appearing, I set the text colour to the back colour.

This was fine except that the tool-tip window was sized to fit the original mark-up text, which is often very big, so it needed resizing. After some searching, I found the article Calculating a Rich Edit Control Minimum Size by Thales P. Carvalho, which allowed me to calculate the correct size for the tip window. I then re-positioned the window to a sensible place based on the cursor position.

This was enough to display basic formatted text in a tip window, but I wanted to be able to support embedded images. To implement this in a rich edit control, it is necessary to give the control an OLE callback handler (a pointer to an IRichEditOleCallback COM object). This is required to allow the control to allocate memory for the storage of embedded items. I added the interface code from the MFC's CRichEditView to my control. The only method that needed implementing was GetNewStorage(), so all other methods simply return S_OK.

Documentation

The CRichToolTipCtrl class has just one public function, in addition to the default constructor and virtual destructor:

static CString MakeTextRTFSafe(LPCTSTR lpszText);

This static function takes a text string, and escapes special characters to make the text acceptable for RTF.

License

Share

About the Author

Originally from an electronics background, I moved into software in 1996, partly as a result of being made redundant, and partly because I was very much enjoying the small amount of coding (in-at-the-deep-end-C) that I had been doing!

I swiftly moved from C to C++, and learned MFC, and then went on to real-time C on Unix. After this I moved to the company for which I currently work, which specialises in Configuration Management software, and currently program mainly in C/C++, for Windows. I have been gradually moving their legacy C code over to use C++ (with STL, MFC, ATL, and WTL). I have pulled in other technologies (Java, C#, VB, COM, SOAP) where appropriate, especially when integrating with third-party products.

In addition to that, I have overseen the technical side of the company website (ASP, VBScript, JavaScript, HTML, CSS), and have also worked closely with colleagues working on other products (Web-based, C#, ASP.NET, SQL, etc).

For developing, I mainly use Visual Studio 2010, along with an in-house-designed editor based on Andrei Stcherbatchenko's syntax parsing classes, and various (mostly freeware) tools. For website design, I use Dreaweaver CS3.

When not developing software, I enjoy listening to and playing music, playing electric and acoustic guitars and mandolin.

Can anyone confirm/deny/help with the issue I'm having of not being able to set things like tab-stops in the RTF used by the tooltip - i.e. they're just discarded.

EDIT - I've worked out that the tabs are being ignored because the minimum tooltip size is calculated without taking them into account and so they're lost as the edit control tries to draw them into a space they won't fit into. Will keep looking...

Any help appreciated.

Thanks,
Phil.

SOLVED: actually, a call to RequestResize in the RTF control adapts the text somewhat to the size of the rectangle it's being displayed in, which is exactly what we don't want it to do. I.e. if there isn't enough room to take the custom set tabstops into account, they're quietly ignored, and the required size with a normal tabstop is used instead. But if you make the rectangle big enough to accommodate the custom tab stops, they will be used.
WORK-AROUND: I cannot think of a work-around that works iteratively to find the width of edit control needed for generic RTF with custom tab-stops. Instead, what I used was a formatted RTF table with white borders. This maintains it's size and RequestResize works properly with it.

I have successfully deployed your code using VS 2010 (Win 7/64-bit) to create a CRichEditView SDI interface that put's me well on the road to building an 'Intellisense' like interface. I have two questions:

1 - is there some way to stop the flickering (see previous posts on this problem) ?
2 - would it be possible to insert a control, say a combo box, as well as a tooltip message ?

According to the P. Vickery, this code gets the minimium size for a rich edit control, and is
taken from http://www.codeproject.com/richedit/richeditsize.asp. That author states:

"Do note that, in the TCX Message Box class, I do all this calculation and resizing
before I actually display the window. Otherwise, it will flick crazily as the
application traverses the binary search loop. Therefore, if you need to recalculate
the Rich Edit Control size when it's already visible, you must first freeze the
parent window redraw, or you should move the Rich Edit Control to outside of the
visible area, do all the calculation and, when it's done, you get it back to the
visible area."

Further down a posting in the above article states:
If you set the ES_AUTOHSCROLL style on the rich edit control, the rect returned
in EN_REQUESTRESIZE will contain the actual rect needed to contain all of the text
without any wrapping.

I tried this but can't get it to work. Has anyone else tried this?

Thanks for sharing this great work. I defy anyone to find another publicly available C++ source code that shows how to create tooltips in a CRichEditView. Believe me, I have spent alot of time looking.

The tooltip in your demo can't display more than one image, only the first occurence is displayed. Whatever its location in the text, whatever image it is. Also some images didn't work when displayed in the tooltip but work fine in the rich edit. Your class _RichToolTipCtrlCookie is buggy.

I was trying out different files to replace the supplied Test.rtf, to see what would happen. They happen to have more lines than will fit in the multiline RichEdit field (which may or may not be a factor).

Here are links to two files I used that had problems:
www.berbible.org/misc/Rtf17_Highlight_sa_Super.rtf
www.berbible.org/misc/Ps119.rtf

When I hover over the multiline RichEdit field that has been pre-filled with the contents of Rtf_Highlight_sa_Super.rtf, it works ok the first time (and sometimes the second time). Subsequent hovers cause the tooltip to be displayed twice. It shows the contents once briefly, flashes, and then re-displays.

With the long Ps119.rtf, it redisplays continuously and never "settles down".

I've looked into this behaviour, and found that this is a problem in any multi-line tool-tip whose window overlaps the cursor position (i.e. not just in my control). You can fix it in my control by adding some code into the OnShow method:

We had some issues with a multi-monitor setup when the secondary monitor was on the right of the primary one. The tooltips worked fine on the main monitor or when the secondary monitor was on the left of the main monitor, but when it was on the right, tooltips on this secondary monitor would appear at the very left of the screen.
I took the liberty of changing a few lines in CRichToolTipCtrl::OnShow from

if ((size.cx + rc.left) > rcDesktop.Width())
rc.left = max(rcDesktop.left, rc.left - ((rc.left + size.cx) - rcDesktop.Width()));
// position it above the mouse if it would go off the bottom of the screen
// but don't move it off the top of the screen
if ((size.cy + rc.top) > rcDesktop.Height())

to

if ( (size.cx + rc.left) >= rcDesktop.right )
rc.left = std::max( rcDesktop.left, rcDesktop.right - size.cx );
// position it above the mouse if it would go off the bottom of the screen
// but don't move it off the top of the screen
if ((size.cy + rc.top) >= rcDesktop.bottom )
rc.top = std::max( rcDesktop.top, (ptCursor.y - 16) - size.cy);

I'm using RichToolTipCtrl for a CComboBox. It is working fine for CButtons and CEdit controls, but I must be incorrectly implementing it for the combo box. Here is the way I am doing it:

In InitDialog:

m_tip.Create();

m_tip.AddTool(GetDlgItem(IDC_COMBO_TRANS_X_TYPE), " ");

Then I override UpdateDate() and add the following:
*******************************************************************
CWnd* editXRate = this->GetDlgItem(IDC_COMBO_TRANS_X_TYPE);
CString strXrate = "";
if (editXRate)
editXRate->GetWindowText(strXrate);
m_tip.UpdateTipText(strXrate, GetDlgItem(IDC_COMBO_TRANS_X_TYPE));
*******************************************************************
This is exactly the way I coded for the CEdit contorls on the dialog, and it works fine for them, but no tooltips show up for the CComboBox.

You are not doing anything wrong. Unfortunately this is due to the make up of combo box controls. If the combo box is set to the drop-list style, then you should find that the tool-tip works correctly, but if the combo uses the drop-down style, then the edit control will not show the tool-tip, as the edit control is a completely separate control.

To get tool-tips to work, you will need to get the handle of the edit control, and set the tool on that control as well as the combo itself.

If targetting Win98 or later, then there is an easy means of getting the edit control's handle, by using CComboBox::GetComboBoxInfo(). There are several articles on CodeProject which include methods of doing this. If you target earlier platforms and don't want to use this call, you can catch the edit control in a WM_CTLCOLOR handler. See my ComboBoxCS article[^] for where I have code which uses GetComboBoxInfo to get the list box, and falls back on the WM_CTLCOLOR method on earlier platforms.

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

there is another problem:
If I call UpdateTipText when the tooltip is visible, the tolltip flickers significant (even with the same rtf string).
I think you calculate the size several times, and this causes a number of repaintings.
Do you have any idea, how to bypass this problem?