The MFC OLE Architecture for Component Programs

We're not going into too many details here—just enough to allow you to understand the new files in the next example. You need to know about three new MFC base classes—COleIPFrameWnd, COleServerDoc, and COleServerItem.

When you use AppWizard to generate an OLE component, AppWizard generates a class derived from each of the base classes, in addition to an application class, a main frame class, and a view class. The COleIPFrameWnd class is rather like CFrameWnd. It's your application's main frame window, which contains the view. It has a menu associated with it, IDR_SRVR_INPLACE, which will be merged into the container program's menu. When your component program is running in place, it's using the in-place frame, and when it's running stand-alone or embedded, it's using the regular frame, which is an object of a class derived from CFrameWnd. The embedded menu is IDR_SRVR_EMBEDDED, and the stand-alone menu is IDR_MAINFRAME.

The COleServerDoc class is a replacement for CDocument. It contains added features that support OLE connections to the container. The COleServerItem class works with the COleServerDoc class. If components never supported OLE linking, the functionality of the two classes could be combined into one class. Because stand-alone component programs do support linking, the MFC architecture dictates that both classes be present in all components. You'll see in the EX28C example that we can make our own simple mini-server without this division.

Together, the COleServerItem class and the COleServerDoc class implement a whole series of OLE interfaces, including IOleObject, IDataObject, IPersistStorage, and IOleInPlaceActiveObject. These classes make calls to the container, using interface pointers that the container passes to them. The important things to know, however, are that your derived CView class draws in the component's in-place-active window and that the derived COleServerItem class draws in the metafile on command from the container.