I'm a little nervous to introduce my first code here.
CHiliteEditView is a small reusable class derived from
CEditView that highlights the current caret line, something like the famous editor program UltraEdit does. I wrote this class just for fun, and I like MFC very much.
How to use?
CHiliteEditView in your project is fairly easy, just add HiliteEditView.cpp and HiliteEditView.h to your project, and add the following include line:
<PRE lang=c++>#include "HiliteEditView.h"
to your stdafx.h, then replace
CHiliteEditView in yourview.cpp and yourview.h files. Then compile and run.
If your project doesn't use
CEditView as the base class, but another class, and you want to try this funny stuff, all you have to do is change the view's base class to
CHiliteEditView, in the class declaration and implementation and message map declarations.
I think it is easier for me to make it than to explain how I made it. First problem is when to highlight the caret line? The answer is: after the control's normal paint action. When we enter some text, or click the mouse, or scroll the view, the Edit control will repaint itself. If we want to paint some extra stuff, it is a great chance to do so at that time, just after the control's normal repaint actions.
Obviously, we must handle the following messages:
WM_PAINT - main place when the control needs repainting.
WM_LBUTTONDOWN - when we click in the control's area, the caret may have moved to another line, so we have to highlight the new line and repaint the previous highlighted line to its normal state.
WM_KEYDOWN - when we move the caret by arrow keys, or PgDn/PgUp etc...
WM_MOUSEMOVE - when we drag to select, it also needs to update the hilite bar.
WM_CHAR - why is it needed? Isn't
WM_KEYDOWN enough? Actually I first wrote the class in
CRichEditView without handling
WM_CHAR and it worked just fine. But when I tried to rewrite it in
CEditView, it didn't repaint when I entered a char. Finally I found the reason: when entering a char in RichEdit control, it updates the screen by sending a
WM_PAINT; this doesn't happen with the Edit control - it updates the screen by drawing on the screen directly in the
WM_CHAR message handler (or others?) and does not send a
int GetCaretLine() const - returns the line number which contains the caret.
void GetLineRect(int nLine, LPRECT lpRect) const - gets the rectangle bound of the specified line in client coordinates.
virtual void DrawCaretLine(BOOL bInPaint = FALSE) - highlights the line containing the caret. Can be overridden to implement other kinds of hilite.
I would say some more words on
<PRE lang=c++>void CHiliteEditView::DrawCaretLine(BOOL bInPaint)
int nLine = GetCaretLine();
// for effective we need not redraw when we
// just move caret in the same line using arrow keys, simply return.
if (nLine == m_nCaretLine && !bInPaint)
int nLineFirst = GetEditCtrl().GetFirstVisibleLine();
int nLineLast = GetEditCtrl().LineFromChar(
// hide caret, else it will be ugly.
if (m_nCaretLine >= nLineFirst && m_nCaretLine <= nLineLast)
// in this section we must not make WM_PAINT a loop
// so don't let OnPaint() call our DrawCaretLine()
m_bCanPaint = FALSE;
// update immediately
m_bCanPaint = TRUE;
// we change the caret line color by ROP
if (nLine >= nLineFirst && nLine <= nLineLast)
bmp.CreateCompatibleBitmap(&dc, rect.Width(), rect.Height());
CBitmap* pSaveBmp = dcMem.SelectObject(&bmp);
CBrush br(RGB(0, 0, 255));
dcMem.FillRect(CRect(0, 0, rect.Width(), rect.Height()), &br);
// "capture" the line into our memory dc, and "INVERT" it
dcMem.BitBlt(0, 0, rect.Width(), rect.Height(),
&dc, rect.left, rect.top, SRCINVERT
// blt it back to origin place, but change colors
dc.BitBlt(rect.left, rect.top, rect.Width(), rect.Height(),
&dcMem, 0, 0, SRCCOPY
m_nCaretLine = nLine;
First, we compare the previous and current caret lines to decide if we need to paint. Normally we needn't repaint twice in the same line, but when handling
WM_PAINT, it always needs to repaint because of scrolling. This is the purpose of the
bInPaint. In the
WM_PAINT handler, we call
bInPaint set to
TRUE, and in other cases, we just forget the parameter, which is default to
When the caret position changes, before we paint a hilite bar in the new place, we have to erase the old one. We simply invalidate the previous line rectangle and force
WM_PAINT to handle it. There is another important thing here to indicate that the
WM_PAINT handler must not call
DrawCaretLine() in this case, otherwise it will go into a loop. The
OnPaint() handler looks like this:
<PRE lang=c++>void CHiliteEditView::OnPaint()
So we can set
TRUE to disable this loop, and restore
FALSE immediately after repainting.
Finally, I appreciate your enduring my angularity English. Thank you!