SAMPLE: RichEdit.exe - Inserts OLE Object Capabilities

• Microsoft Win32 Software Development Kit (SDK)
• Microsoft Windows 2000

SUMMARY

RichEdit control supports embedding and inplace-activating OLE Objects. To add these capabilities to a RichEdit control in your application, an independent service vendor (ISV) must implement certain OLE interfaces. The RichEdit sample shows how these interfaces are implemented and other implementation details that are required in conjunction with the OLE interfaces to embed and inplace-activate OLE objects.

MORE INFORMATION

The following file is available for download from the Microsoft Download Center. Click the file name below to download the file:

RichEdit.exe

http://www.microsoft.com/downloads/search.asp

• 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.

• 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();
        } 

Additional query words:

Keywords : kbfile kbsample kbCtrl kbNTOS kbNTOS351 kbWinOS2000 kbRichEdit kbSDKWin32 kbGrpUser kbWinOS95 kbWinOS98
Version : WINDOWS:
Platform : WINDOWS
Issue type :