SAMPLE: RichEdit.exe - Inserts OLE Object Capabilities (141549)

MORE INFORMATION

The following file is available for download from the Microsoft Download Center:
For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base: Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file. An ISV must implement the following OLE interfaces to add the embedding and inplace-activating capabilities to the RichEdit control in their application:

• IRichEditOleCallback, which is used by a RichEdit control to retrieve OLE-related information from its client. This interface is passed by the client application to the RichEdit control via EM_SETOLEINTERFACE message. This is a RichEdit control's custom interface.
• IOleInPlaceFrame, which is used to control the container's top-level frame window. In addition, implementing this interface involves implementing IOleWindow and IOleInPlaceUIWindow interfaces also, because IOleInPlaceFrame is inherited from IOleInPlaceUIWindow, which in turn inherits IOleWindow.

There are a few caveats that are important to enable this feature work to properly:

• The Frame window, which will be the parent of the tool bar and status bar, needs to be created with the WS_CLIPCHILDREN style. If this style is not present, your applications will exhibit some painting problems when an object is inplace-active in your RichEdit control.
• The RichEdit control itself should be created with WS_CLIPSIBLING style. Here too, if the style is not present, RichEdit control will exhibit painting problems when the Object creates child windows during inplace- active.
• When destroying the RichEdit control, your application should deactivate any inplace-active Object and call IOleObject->Close() on all the embedded objects in the RichEdit control. If this is not done, some object applications may not close down, thus causing them to stay in memory, even after the RichEdit control is destroyed. Here is a code snippet that demonstrates how to handle closing of OLE Objects:

        if (m_pRichEditOle)
        {
           HRESULT hr = 0;
  
           // 
           // Start by getting the total number of objects in the control.
           // 
           int objectCount = m_pRichEditOle->GetObjectCount();
  
           // 
           // Loop through each object in the control and if active
           // deactivate, and if open, close.
           // 
           for (int i = 0; i < objectCount; i++)
           {
              REOBJECT reObj;
               ZeroMemory(&reObj, sizeof(REOBJECT));
              reObj.cbStruct  = sizeof(REOBJECT);
  
              // 
              // Get the Nth object
              // 
              hr = m_pRichEditOle->GetObject(i,&reObj,REO_GETOBJ_POLEOBJ);
              if(SUCCEEDED(hr))
              {
                 // 
                 // If active, deactivate.
                 // 
                 if (reObj.dwFlags && REO_INPLACEACTIVE)
                    m_pRichEditOle->InPlaceDeactivate();
  
                 // 
                 // If the object is open, close it.
                 // 
                 if(reObj.dwFlags&&REO_OPEN)
                    hr = reObj.poleobj->Close(OLECLOSE_NOSAVE);
  
                    reObj.poleobj->Release();
              }
           }
           m_pRichEditOle->Release();
        }