CRichEditView/CRichEditDoc Bug Work-Around

The Problem

This article details a bug found with using a CRichEditDoc in conjunction with several views and was inspired by Dark Mage in one of his posts. He was attempting to use a CRichEditView in a splitter window in an "explorer" type of the application.

My theory is that this bug affects anyone who is attempting to use multiple views (with at least one of them being derived from CRichEditView) and a CRichEditDoc-derived document class.

The problem is that when any view other than the CRichEditView is activated and the Edit menu is selected, an Assert is thrown! When you select the Edit menu, the system routes the CommandUI updates before the menu is displayed. The MFC framework then calls the document to update the command for the name of the OLE object embedded in the document and the Verb submenu accessed from this object command. (The Verb submenu contains all the verb commands available for the object.) This in turn results in the calling of the GetPrimarySelectedItem function to retrieve the currently selected OLE item in the specified view. Here's the crux of the problem. The CRichEditDoc just takes for granted that the only view it is dealing with is a CRichEditView-derived view (which is not necessarily true!).

Fortunately, the GetPrimarySelectedItem function is virtual, and it can be overridden. However, because this function is not on the available list of virtual functions in Class Wizard, you must "manually" insert the function into your code.

The Solution

In your document class' include file, declare (insert) the following member function override.

virtual COleClientItem* GetPrimarySelectedItem(CView* pView);

Now, in your implementation file, insert the following:

COleClientItem* CYourRichEditDoc::GetPrimarySelectedItem(CView *pView)
    // CRichEditDoc's implementation asserts here
    // we just stop processing since the active view is not 
    // a CRichEditView class
    return NULL;

  return ((CRichEditView*)pView)->GetSelectedItem();


This fixes the bug. I have tested this fix for MDI, SDI, for multiple views and swappable views embedded in a dialog and so far it works in all those scenarios. If you find any problem related to the above, please send me e-mail. I am trying to find out whether this is a known bug (feature) and have contacted Microsoft. Hopefully, I will get an answer to this soon.

About the Author

John Z. Czopowik VC++ MVP

Microsoft VC++ MVP


  • a question

    Posted by Legacy on 10/26/2003 12:00am

    Originally posted by: lotus

    how to work with two CRichEditView-Drivied view and tow CRichEditDoc-Drivied Doc?

  • Using 2 CRichEditViews with 1 CRichEditDoc

    Posted by Legacy on 01/17/2002 12:00am

    Originally posted by: Dand

    I'm attempting to use a splitter type application that has 2 CRichEditViews pointing to the same CRichEditDoc. This was all fine and well until I tried embedding objects in one or both of the views. The problem seems to be similar to the above bug except that this fix does not address the case where more then one of the multiple views happens to be another CRichEditView.

    From looking at the code, it appears that CRichDocument::GetView() makes a similiar assumption in that the first view it finds of type CRichEditView is the correct one which in fact is not true in this case. I see from the documentation that you are only supposed to use one CRichEditDoc per CRichEditView (apparently, for this reason). But, perhaps someone has a solution or suggestion.


  • Help with PrintPreview

    Posted by Legacy on 04/09/2001 12:00am

    Originally posted by: Maria

    I build an application that displays a text file and provides the various print options.
    I have overridden the basic Printing function but within these overridden functions the MFC provided functions are called
    EX.BOOL CPrintView::OnPreparePrinting(CPrintInfo* pInfo)

    // CRichEditCtrl
    CSize csPaper = GetPaperSize();;
    //Get the Filename
    char Name[40];

    // return CView::OnPreparePrinting(pInfo);
    // default preparation
    return DoPreparePrinting(pInfo);
    However the Print preview doesn't utilize the entire page and comes different to what the actual print out shows
    I have written similar code using CEdit View and it works perfectly.

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • On-demand Event Event Date: September 10, 2014 Modern mobile applications connect systems-of-engagement (mobile apps) with systems-of-record (traditional IT) to deliver new and innovative business value. But the lifecycle for development of mobile apps is also new and different. Emerging trends in mobile development call for faster delivery of incremental features, coupled with feedback from the users of the app "in the wild." This loop of continuous delivery and continuous feedback is how the best mobile …

  • On-demand Event Event Date: September 17, 2014 Another day, another end-of-support deadline. You've heard enough about the hazards of not migrating to Windows Server 2008 or 2012. What you may not know is that there's plenty in it for you and your business, like increased automation and performance, time-saving technical features, and a lower total cost of ownership. Check out this webcast and join Rich Holmes, Pomeroy's practice director of virtualization, as he discusses the future state of your servers, …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds