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.
The following file is available for download from the Microsoft Download Center:
RichEdit.exe
(http://download.microsoft.com/download/platformsdk/sample53/1/w95/en-us/richedit.exe)
For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:
119591
(http://support.microsoft.com/kb/119591/EN-US/
)
How to Obtain Microsoft Support Files from Online Services
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();
}
Back to the top
