Dynamic Runtime Objects: Building Applications Your Users Can Modify at Runtime

Ed Smetak and Jean Caputo

Ed Smetak is vice president of Engineering Software Consulting at NanoSoft Corporation. Jean Caputo is a project management specialist at NanoSoft Corporation. They can be reached at http://www.nanocorp.com.

Managing the development of large software applications can be a big headache. Often, the headache comes from inappropriate object dependencies that creep in as the result of a poor global design framework. If the application needs to be extensible enough to allow customization by users, things get worse as awkward object dependencies mount.

We have found that the concept of dynamic runtime objects can go a long way toward keeping big projects under control by isolating object dependencies. This concept forces developers to segregate code in such a way that the tendency toward inappropriate object dependencies is greatly reduced, while appropriate dependencies are handled in a uniform, understandable, and manageable fashion. The result is an application that is well organized and easy to extend—even by users, and even at runtime.

In this article, we will show you how to solve common problems of complicated application architectures by structuring classes to your utmost advantageæimplementing generic behavior high up in the inheritance chain and pushing context-specific behavior down to the most
derived classes. With the concept of dynamic objects, you can take this strategy for structuring classes to the limit and allow new object classes to be introduced to the application at runtime.

Rather than focusing on an isolated technology area, this article takes a stab at the big picture using an application of arbitrary complexity. We are providing a large amount of example code to show you how it can all fit together. All of the concepts will be demonstrated through a series of dynamic runtime objects and views that live in separate MFC Extension DLLs. The objects are hosted by a generic container application called ObjectView. (You can get the complete source code, as well as the ObjectView container app, from the sources listed on page 5.) We hope that the ideas and components presented here will be a useful addition to your box of development tools.

We’ll start by showing you how easy it is to build a DLL that houses a simple dynamic runtime object and an associated view. Then we’ll look at three key components that make it work—a class broker, a view broker, and an object broker. Of particular interest is the object broker, which uses ActiveX™ structured storages and whisks objects in and out of memory as needed, minimizing your application’s overhead.

We’ll move on to introduce an extensible Dynamic
Object design pattern that you can use to structure classes and manage object dependencies in your most complex application. The pattern is extensible to situations that require multiple views on complex objects with intricate interdependencies. We’ll use the pattern to create three different dynamic objects that live in MFC Extension DLLs. Each DLL houses a dynamic object class and associated graphical user interface (GUI) classes. The first DLL
demonstrates how a view should interact with a dynamic ob­ject and how to handle persistent data for dynamic objects. The second DLL demonstrates how to handle object
interde­pendencies—a common source of problems in many applications. The third DLL demonstrates the concept of inter­­­changeable classes, which is useful to provide hooks for customizing apps at runtime. We’ll finish up with a few words about how the dynamic object con­­cepts presented here compare with COM, ActiveX, and OLE technologies.

We’ll be using class diagrams and interaction diagrams to illustrate our design concepts. The class diagrams, based on the Object Modeling Technique (OMT), depict classes, their structures, and the static relationships between them (Figure 1 shows the key to the OMT diagrams.) The interaction diagrams, taken from the Booch method, depict the order in which requests between objects get executed.

Figure 1 OMT Notation Key

Building a Simple Dynamic Object and View

Let’s jump right in with a simple example to demonstrate how easy it is to use dynamic objects. We’ll build an MFC Extension DLL called Simple.dll that will be incorporated into our host application at runtime—without recompiling—thanks to the services of our class, view, and object brokers. Simple.dll will house a dynamic object class called CSimple­Object and an associated view class called CSimpleView (see Figure 2).

Figure 2 CSimpleObject and CSimpleView

Go to Visual C++®, open a new project workspace, and choose the MFC DLL AppWizard. Make sure to specify an MFC Extension DLL using MFC as a shared DLL. CSimpleObject is derived from a base class called CDynamicObject that we’ll discuss later. For this example, all we’ll include is a constructor, a destructor, and a Serialize function. All three of these functions will be just empty shells. We’ll look at more interesting examples later. Make sure to use the DECLARE_
SERIAL macro in your class definition and the IMPLEMENT_SERIAL macro in your implementation file to allow the object to be dynamically created and serialized:

IMPLEMENT_SERIAL(CSimpleObject,
CDynamicObject,1)

CSimpleObject::CSimpleObject()

{

// nothing required for this

// simple example

}

CSimpleObject::~CSimpleObject()

{

// nothing required for this

// simple example

}

void CSimpleObject::Serialize(CArchive&

archive)

{

// remember to call the base class

CDynamicObject::Serialize(archive);

}

Next, add some code for the CSimple­View class. Use the MFC ClassWizard to create a class derived from a CForm­View. ClassWizard automatically
adds the DECLARE_DYN­CREATE macro to the class definition and the
IMPLEMENT_ DYNCREATE macro to the implementation file. Note that we’ve changed the base class from CForm­View to CNSFlexFormView. CNSFlexFormView is from the NSViews C++ library. This library gives all the views in our sample code some distinctive resizing behavior:

IMPLEMENT_DYNCREATE(CSimpleView, CNSFlexFormView)

CSimpleView::CSimpleView() : CNSFlexFormView(CSimpleView::IDD)

{

// nothing required for this simple example

}

A basic rule for good architectures is to keep user interface object classes separate from functional object classes. In our case, CSimpleView is our user interface class and CSimple­Object is our functional class. It’s OK for CSimple­View to hold a reference to CSimpleObject, but CSimple­Object should have no knowledge of CSimpleView. How does CSimpleView get hold of the associated CSimpleObject? Here’s where the view broker and object broker come in. The view broker will send a WM_OBJECT­INFO custom message that includes a unique key associated with the dy­namic object we need. Given the key, we can get hold of our dynamic object from the object broker. A pointer to the object broker is also passed with the message. CSimpleView::
OnObjectInfo (see Figure 3) shows how to handle the WM_OBJECTINFO message.

Figure 3 Simple Dynamic Object and View

OnObjectInfo Method of CSimpleView

BEGIN_MESSAGE_MAP(CSimpleView, CNSFlexFormView)

//{{AFX_MSG_MAP(CSimpleView)

// NOTE - the ClassWizard will add and remove

// mapping macros here.

//}}AFX_MSG_MAP

ON_MESSAGE(WM_OBJECTINFO,OnObjectInfo)

END_MESSAGE_MAP()

LRESULT CSimpleView::OnObjectInfo(WPARAM wParam, LPARAM lParam)

{

ObjectInfoMessage* pObjectInfoMessage =

(ObjectInfoMessage*)(lParam);

CObjectBroker* pObjectBroker = pObjectInfoMessage->pObjectBroker;

CObjectInfo* pObjectInfo =

pObjectBroker->GetObjectInfoByKey(pObjectInfoMessage->

pszObjectKey);

ASSERT(pObjectInfo);

m_pSimpleObject = (CSimpleObject*)pObjectInfo->GetObject();

ASSERT(m_pSimpleObject);

ASSERT(m_pSimpleObject->IsKindOf(RUNTIME_CLASS(CSimpleObject)));

return 1;

}

DllMain Function for Simple.dll

extern "C" int APIENTRY

DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)

{

if (dwReason == DLL_PROCESS_ATTACH)

{

TRACE0("SIMPLE.DLL Initializing!\n");

// Extension DLL one-time initialization

AfxInitExtensionModule(SimpleDLL, hInstance);

// Insert this DLL into the resource chain

new CDynLinkLibrary(SimpleDLL);

}

else if (dwReason == DLL_PROCESS_DETACH)

{

TRACE0("SIMPLE.DLL Terminating!\n");

AfxTermExtensionModule(SimpleDLL);

}

return 1; // ok

}

ClassInfo Function Exported from Simple.dll

extern "C" void WINAPI ClassInfo(CLSID& clsidClassID,

CLSID& clsidClassCategory,

CString& csDescription,

CRuntimeClass*& pObjectClass,

CRuntimeClass*& pFrameClass,

CRuntimeClass*& pViewClass)

{

// ID: {34E338C1-86E1-11d0-8984-00008609452B}

CLSID clsidID = { 0x34e338c1, 0x86e1, 0x11d0,

{ 0x89, 0x84, 0x0, 0x0, 0x86, 0x9, 0x45, 0x2b } };

// CATEGORY: {8CEDC521-90AF-11d0-A263-2AC81B000000}

CLSID clsidCategory = { 0x8cedc521, 0x90af, 0x11d0,

{ 0xa2, 0x63, 0x2a, 0xc8, 0x1b, 0x0, 0x0, 0x0 } };

clsidClassID = clsidID;

clsidClassCategory = clsidCategory;

csDescription = "Simple Object";

pObjectClass = RUNTIME_CLASS(CSimpleObject);

pFrameClass = RUNTIME_CLASS(CFlexibleChildFrame);

pViewClass = RUNTIME_CLASS(CSimpleView);

}

When we’re done with the dynamic object, we need to call CDynamicObject::Release. A convenient place to do that is in the destructor for our view:

CSimpleView::~CSimpleView()

{

m_pSimpleObject->Release();

}

The object broker will load and unload DLLs as dynamic objects are created and deleted. The code for DllMain that AppWizard created for us didn’t include a call to AfxTerm­ExtensionModule—it’s unusual for DLLs to be unloaded as we do here. But, if you’re going to unload MFC Extension DLLs, you need to be sure to call AfxTermEx­tensionModule (see Figure 3). Some very mysterious (and bad) things will happen if you forget this detail.

The last thing we have to do is tell the class broker that our DLL houses a dynamic object and associated view. The class broker will load our DLL and search for an exported function called ClassInfo (see Figure 3). ClassInfo must return a class ID, a class category, and a short description for our dynamic object. In addition, ClassInfo must return the runtime classes of our dynamic object, frame, and view. The class ID and class category are easily generated using the Guidgen.exe program that ships with Visual C++. The class ID for each runtime DLL must be globally unique. Later we’ll see that it is useful to identify classes that are interchangeable. The class category is used for this purpose and must be globally unique for each category of interchangeable classes.

Using Dynamic Objects

Now that we’ve built a DLL that contains a dynamic object, let’s run it by using ObjectView, a generic container for dynamic objects. The behavior of the dynamic object and view can be as simple or as complicated as required. What’s important is that we define all that behavior in the DLL. The main application doesn’t know a thing about either of the classes—except that the dynamic object is derived from CDynamicObject. The main application doesn’t even need to include any headers for the classes defined and implemented in the DLL. If you run ObjectView without any DLLs containing dynamic objects in ObjectView’s directory, it’s rather boringæ
just an empty shell (see Figure 4). But copy Simple.dll into ObjectView’s directory and suddenly ObjectView is hosting both the CSimpleObject object and the CSimpleView view (see Figure 5).

Figure 4 ObjectView, no DLLs

Figure 5 Hosting Dynamic Object and View

CSimpleObject and CSimpleView don’t really do much more than display a bitmap that was included in the dialog resource associated with the CForm­View. However, all the hooks are in place for more sophisticated behaviors. Later, in our more complicated examples, we’ll let our imagination go a little further and create some spinning rotors that use threads and persist their state through CDynamic­Object::­Serialize. You’ll be surprised how easy it is, and the objects can be as big and complicated as you want. The dynamic objects can even have complex interdependencies.

The three key components that support this extensibility aren’t that complicated. The class broker registers classes for dynamic objects. The view broker manages views on dynamic objects. The object broker dispenses dynamic objects as needed. We’ll take a look at each of them in detail. But first, we need to introduce one more concept that will be a recurring theme in almost every ingredient of our dynamic object architecture.

Observer Design Pattern

The well-known Observer design pattern provides a useful context for managing object interdependencies. The Observer pattern recognizes that applications are replete with interdependent objects, and a generic method of communicating changes between objects is essential. Communication between subject and observer is best accomplished when the subject object does not need to know anything specific about the observer object except that the observer must be notified of any change. MFC’s document view architecture is a form of the Observer pattern.

Our implementation of the Observer pattern centers on two classes, CSubject and CObserver, which allow interested observers to register with and be notified about changes to interesting subjects (see Figure 6). CSubject::NotifyObservers broadcasts change notifications to all registered COb­servers. CSubject::AttachTo­Subject and CSubject::DetachFromSubject register and unregister CObservers. CObser­ver::Subject­Changed is a virtual function that must be overridden to receive change notifications from CSubjects.

Figure 6 CSubject and CObserver

These classes are a snap to use and can make complex communication among objects manageable and bug-free. For example, the view broker is an observer, the object broker is a subject, and dynamic objects may be either or both. The Observer design pattern is a cornerstone for the Dynamic Object pattern, which we will use to support complicated cases where an object needs to observe multiple subjects as well as be observed by multiple observers.

Class Broker

We need a vehicle to whisk code for object classes into and out of the application’s address space at runtime. CClassBroker and CClassInfo provide this service (see Figure 7). CClassBro­ker::­LoadDLLModules (see Figure 8) is called as part of the application’s initialization. LoadDLLModules searches the application’s directory, loads each DLL residing there via a call to ::Afx­LoadLibrary, and inquires—via a call to ::GetProc­Address—whether a function called ClassInfo is exported from the DLL. If GetProc­Address locates ClassInfo, Class­Info is called to obtain six pieces of information:

• class ID associated with the object in the DLL (must be unique)
  
  
• class category of the object (unique for each category of interchangeable classes)
  
  
• short text description of the object
  
  
• runtime class of the object
  
  
• runtime class of the frame for the object’s view
  
  
• runtime class of the object’s view

Figure 7 CClassBroker and CClassInfo

Figure 8 LoadDllModules Method of CClassBroker

void CClassBroker::LoadDLLModules()

{

char szBuffer[MAX_PATH], szDrive[3], szPath[MAX_PATH];

GetModuleFileName(AfxGetInstanceHandle(),szBuffer,MAX_PATH);

_splitpath(szBuffer,szDrive,szPath,NULL,NULL);

CString csPath = szDrive;

csPath += szPath;

CString csDLLSearch = csPath + "*.dll";

WIN32_FIND_DATA FileData;

HANDLE hFind;

for (BOOL bOK = ((hFind = FindFirstFile(csDLLSearch,&FileData))

!= INVALID_HANDLE_VALUE); bOK;

bOK = FindNextFile(hFind,&FileData))

{

CString csDLL = csPath;

csDLL += FileData.cFileName;

HMODULE hModule = AfxLoadLibrary(csDLL);

ASSERT(hModule);

typedef void (WINAPI* CLASSINFO)(CLSID&,CLSID&,CString&,

CRuntimeClass*&,CRuntimeClass*&,CRuntimeClass*&);

CLASSINFO pClassInfo =

(CLASSINFO)GetProcAddress(hModule,"ClassInfo");

if (pClassInfo)

{

CLSID clsidClassID;

CLSID clsidClassCategory;

CString csDescription;

CRuntimeClass* pObjectClass;

CRuntimeClass* pFrameClass;

CRuntimeClass* pViewClass;

(*pClassInfo)(clsidClassID,clsidClassCategory,

csDescription,pObjectClass,pFrameClass,

pViewClass);

if (GetClassInfo(clsidClassID))

AfxMessageBox(

"CClassBroker::LoadDLLModules - Duplicate class ID");

else

AddClassInfo(clsidClassID,clsidClassCategory,

csDescription,pObjectClass,pFrameClass,

pViewClass,csDLL);

}

AfxFreeLibrary(hModule);

}

}

You’ve already seen a typical implementation of ClassInfo in the Simple.dll example. The information returned from ClassInfo, along with the full path to the associated DLL, is passed to CClassBroker::AddClassInfo. AddClassInfo instantiates a CClassInfo object and adds it to a static list of available CClassInfo objects.

Each DLL is then unloaded via a call to ::AfxFreeLibrary. A DLL only needs to stay loaded if objects defined in the DLL are actually instantiated by the application. CClassIn­fo::­LoadLibrary and CClassInfo::FreeLibrary provide the mechanism to load and unload a DLL as required. It’s important to note that each time a DLL is loaded, the addresses of the runtime classes in the DLL may change. Therefore, LoadLibrary will always need to call ClassInfo to get the current addresses. We’ll see how LoadLibrary is called to do its work when we look at the object broker.

View Broker

MFC’s AppWizard generates code that creates a single CMultiDocTemplate as part of the application object’s InitInstance function. CMultiDocTemplate ties together the document, frame window, and view. But we know nothing about the type of view or frame our runtime object will need until the DLL is loaded at runtime. CViewBroker, CViewInfo, and CMultiDocTemplateEx provide a mechanism that will let us open a view, or even multiple views, on our dynamic object (see Figure 9). In order to use these classes, the code that AppWizard generates for us needs to be altered to create a CMultiDocTemplateEx instead of a CMultiDocTemplate:

CMultiDocTemplateEx* pDocTemplate = new CMultiDocTemplateEx(

IDR_OBVIEWTYPE,

RUNTIME_CLASS(CObjectViewDoc),

RUNTIME_CLASS(CFlexibleChildFrame),

RUNTIME_CLASS(CObjectBrokerView));

AddDocTemplate(pDocTemplate);

Figure 9 CMultiDocTemplateEx, CViewBroker, and CViewInfo

Here’s the CMultiDocTemplateEx constructor. It saves the runtime classes of the frame and view for later use:

CMultiDocTemplateEx::CMultiDocTemplateEx(UINT nIDResource,

CRuntimeClass* pDocClass,

CRuntimeClass* pFrameClass,

CRuntimeClass* pViewClass) :

CMultiDocTemplate(nIDResource,

pDocClass,pFrameClass,pViewClass)

{

m_pDefaultFrameClass = pFrameClass;

m_pDefaultViewClass = pViewClass;

}

To open a view on one of our dynamic objects, call CView­Broker::OpenView (see Figure 10) with the key to the object. If a view is already open on the object, OpenView activates it. Otherwise, OpenView calls CViewBroker::Open­Dupli­cate­­View (see Figure 10) to create a new view.

Figure 10 View Broker Code

OpenView Method of CViewBroker

void CViewBroker::OpenView(LPCTSTR pszObjectKey)

{

CViewInfo* pViewInfo;

if (m_mapViewInfo.Lookup(pszObjectKey,(void*&)pViewInfo))

{

CView* pView = (CView*)pViewInfo->m_listViews.GetHead();

CMDIChildWnd* pFrameWindow =

(CMDIChildWnd*)pView->GetParent();

if (pFrameWindow->IsIconic())

pFrameWindow->MDIRestore();

pFrameWindow->MDIActivate();

return;

}

pViewInfo = new CViewInfo();

m_mapViewInfo.SetAt(pszObjectKey,pViewInfo);

OpenDuplicateView(pszObjectKey);

}

OpenDuplicateView Method of CViewBroker

void CViewBroker::OpenDuplicateView(LPCTSTR pszObjectKey)

{

CObjectInfo* pObjectInfo = m_pObjectBroker->

GetObjectInfoByKey(pszObjectKey);

CClassInfo* pClassInfo =

CClassBroker::GetClassInfo(pObjectInfo->GetClassID());

CMultiDocTemplateEx* pDocTemplate =

(CMultiDocTemplateEx*)m_pObjectDoc->GetDocTemplate();

CFrameWnd* pFrameWnd = pDocTemplate->CreateNewFrame(

m_pObjectDoc,pClassInfo->GetFrameClass(),

pClassInfo->GetViewClass());

CView* pView =

(CView*)pFrameWnd->

GetDescendantWindow(AFX_IDW_PANE_FIRST,TRUE);

ASSERT(pView->IsKindOf(pClassInfo->GetViewClass()));

CViewInfo* pViewInfo = NULL;

m_mapViewInfo.Lookup(pszObjectKey,(void*&)pViewInfo);

ASSERT(pViewInfo);

pViewInfo->m_listViews.AddTail(pView);

ObjectInfoMessage structObjectInfoMessage;

structObjectInfoMessage.pObjectBroker = m_pObjectBroker;

structObjectInfoMessage.pszObjectKey = pszObjectKey;

VERIFY(pView->SendMessage(WM_OBJECTINFO,0,

(LPARAM)&structObjectInfoMessage));

SetWindowTitles();

pDocTemplate->InitialUpdateFrame(pFrameWnd,m_pObjectDoc);

}

CreateNewFrame Method of CMultiDocTemplateEx

CFrameWnd* CMultiDocTemplateEx::CreateNewFrame(CDocument* pDoc,

CRuntimeClass* pFrameClass, CRuntimeClass* pViewClass)

{

if (pFrameClass)

m_pFrameClass = pFrameClass;

else

m_pFrameClass = m_pDefaultFrameClass;

if (pViewClass)

m_pViewClass = pViewClass;

else

m_pViewClass = m_pDefaultViewClass;

return CMultiDocTemplate::CreateNewFrame(pDoc,NULL);

}

CViewBroker::OpenDuplicateView asks the CClass­Broker for the associated CClassInfo for the requested key. Now we can call CMultiDocTemplateEx::CreateNewFrame with the runtime classes of the frame and view we get from CClassInfo. After the view is created, we send it a WM_
OBJECTINFO custom message that includes the key for the object and a pointer to the object broker.

CMultiDocTemplateEx::CreateNewFrame (see Figure 10) performs some slight of hand to trick CMultiDocTem­plate::CreateNewFrame into using the specified MDI frame and view.

Object Broker

The object broker conserves memory resources by keeping objects in memory only as long as they are needed. This also makes saving files almost instantaneous since there are fewer objects living in memory. In addition, the object broker allows you to store and serialize references to dependent objects as simple keys. The object broker is implemented using three classes: CObjectBroker, CObjectInfo, and CDynamicObject (see Figure 11).

Figure 11 CObjectBroker, CObjectInfo, and CDynamicObject

CDynamicObject provides a base class for our dynamic objects. Each dynamic object derived from CDynamicObject is added to a CObjectBroker container object along with an associated CObjectInfo object. When the CDynamicObject object is created, it actually goes into an ActiveX structured storage living in the application’s compound file. Each CDynamicObject object resides in the structured storage on disk until you need it. At that time, get hold of the associated CObjectInfo object and then ask it to bring your dynamic object from the structured storage into memory. Everything happens transparently, so it’s easy to use. Let’s see what makes it work.

A dynamic object derived from CDynamicObject is created and inserted into a CObjectBroker object along with an associated CObjectInfo object, using CObjectBroker::Add (see Figures 12 and 13). Add takes one of the class IDs registered with CClassBroker and returns a unique key for the new dynamic object. First, Add generates a unique key, a unique default object name, and a unique ActiveX structured storage stream name. Then, Add instantiates a new CObject­Info, assigns the key, object name, and stream name, and then calls CObjectInfo::Set­ClassID (see
Figure 13).

Figure 12 Adding a Dynamic Object to CObjectBroker

Figure 13 Object Broker Code

Add Method of CObjectBroker

BOOL CObjectBroker::Add(REFCLSID rclsid, CString& rcsKey)

{

CString csName, csStream;

GenerateUniqueKey(rcsKey);

GenerateUniqueName(csName);

GenerateUniqueStream(csStream);

CObjectInfo* pObjectInfo = new CObjectInfo;

pObjectInfo->SetKey(rcsKey);

pObjectInfo->SetName(csName);

pObjectInfo->SetStream(csStream);

pObjectInfo->SetObjectBroker(this);

if(!pObjectInfo->SetClassID(rclsid))

{

delete pObjectInfo;

return FALSE;

}

m_mapObjectsByKey.SetAt(rcsKey,pObjectInfo);

m_mapObjectsByName.SetAt(csName,pObjectInfo);

m_mapObjectsByStream.SetAt(csStream,pObjectInfo);

NotifyObservers(OBJECT_BROKER_ADDED_OBJECT,&rcsKey);

return TRUE;

}

SetClassID Method of CObjectInfo

BOOL CObjectInfo::SetClassID(REFCLSID rclsid)

{

ASSERT(m_pDynamicObject == NULL);

m_clsid = rclsid;

CClassInfo* pClassInfo = GetClassInfo();

if (pClassInfo == NULL)

return FALSE;

pClassInfo->LoadLibrary();

CRuntimeClass* pObjectClass = pClassInfo->GetObjectClass();

ASSERT(pObjectClass);

if (!pObjectClass->IsDerivedFrom(RUNTIME_CLASS(CDynamicObject)))

return FALSE;

m_pDynamicObject =

(CDynamicObject*)pObjectClass->CreateObject();

ASSERT(m_pDynamicObject);

ASSERT(m_pDynamicObject->IsKindOf(RUNTIME_CLASS(CDynamicObject)));

m_pDynamicObject->SetObjectInfo(this);

m_pDynamicObject->OnCreatedNewObject();

StoreObject(TRUE);

return TRUE;

}

StoreObject Method of CObjectInfo

void CObjectInfo::StoreObject(BOOL bFreeMemory)

{

LPSTORAGE pObjectStorage = GetObjectBroker()->GetObjectStorage();

COleStreamFile StreamFile;

if (StreamFile.OpenStream(pObjectStorage,GetStream())== FALSE)

VERIFY(StreamFile.CreateStream(pObjectStorage,GetStream()));

CArchive Archive(&StreamFile,

CArchive::store|CArchive::bNoFlushOnDelete);

Archive.m_bForceFlat = FALSE;

Archive << m_pDynamicObject;

Archive.Close();

StreamFile.Close();

pObjectStorage->Commit(STGC_DEFAULT);

pObjectStorage->Release();

if (bFreeMemory)

{

delete m_pDynamicObject;

m_pDynamicObject = NULL;

}

}

GetObject Method of CObjectInfo

CDynamicObject* CObjectInfo::GetObject()

{

if (m_pDynamicObject)

{

m_pDynamicObject->AddRef();

return m_pDynamicObject;

}

LPSTORAGE pObjectStorage = GetObjectBroker()->GetObjectStorage();

COleStreamFile StreamFile;

VERIFY(StreamFile.OpenStream(pObjectStorage,GetStream()));

CArchive Archive(&StreamFile,

CArchive::load|CArchive::bNoFlushOnDelete);

Archive.m_bForceFlat = FALSE;

Archive >> m_pDynamicObject;

Archive.Close();

StreamFile.Close();

pObjectStorage->Release();

ASSERT(m_pDynamicObject);

ASSERT(m_pDynamicObject->IsKindOf(RUNTIME_CLASS(CDynamicObject)));

m_pDynamicObject->SetObjectInfo(this);

m_pDynamicObject->AddRef();

m_pDynamicObject->OnSerializedObjectFromArchive();

return m_pDynamicObject;

}

GetObjectStorage Method of CObjectBroker

LPSTORAGE CObjectBroker::GetObjectStorage()

{

BSTR bstrObjectStorage = m_csObjectStorageName.AllocSysString();

LPSTORAGE pObjectStorage = NULL;

HRESULT hr = m_pRootStorage->OpenStorage(bstrObjectStorage,

NULL,STGM_SHARE_EXCLUSIVE|STGM_READWRITE|STGM_TRANSACTED,

NULL,0,&pObjectStorage);

ASSERT(SUCCEEDED(hr));

SysFreeString(bstrObjectStorage);

return pObjectStorage;

}

SetRootStorage Method of CObjectBroker

void CObjectBroker::SetRootStorage(LPSTORAGE pRootStorage)

{

if (m_pRootStorage == pRootStorage)

return;

BSTR bstrObjectStorage = m_csObjectStorageName.AllocSysString();

if (m_pRootStorage == NULL)

{

LPSTORAGE pObjectStorage = NULL;

m_pRootStorage = pRootStorage;

if (FAILED(m_pRootStorage->OpenStorage(bstrObjectStorage,

NULL,STGM_SHARE_EXCLUSIVE|STGM_READWRITE,

NULL,0,&pObjectStorage)))

m_pRootStorage->CreateStorage(bstrObjectStorage,

STGM_SHARE_EXCLUSIVE|STGM_READWRITE,

0,0,&pObjectStorage);

pObjectStorage->Release();

}

else

{

m_pRootStorage->MoveElementTo(bstrObjectStorage,

pRootStorage,bstrObjectStorage,STGMOVE_COPY);

m_pRootStorage = pRootStorage;

}

SysFreeString(bstrObjectStorage);

}

OnNewDocument Method and Serialize Method of CObjectDoc

BOOL CObjectDoc::OnNewDocument()

{

if (!COleDocument::OnNewDocument())

return FALSE;

m_pObjectBroker->SetRootStorage(m_lpRootStg);

return TRUE;

}

void CObjectDoc::Serialize(CArchive& ar)

{

COleDocument::Serialize(ar);

m_pObjectBroker->SetRootStorage(m_lpRootStg);

m_pObjectBroker->Serialize(ar);

}

One of the first things that CObjectInfo::SetClassID does is to call CClassInfo::LoadLibrary to insure the DLL containing the code for the dynamic object is loaded. Then, SetClassID calls CClass­Info::­GetObjectClass to obtain the runtime class of the dynamic object to be created. Next, MFC’s dynamic object creation facility is used to breathe life into the dynamic object via a call to CRun­timeClass::CreateObject. After the object is dynamically created, SetClassID gives you a hook to do whatever processing may be appropriate at this time via a call to the virtual function CDynamic­Object::OnCreatedNewObject (which you can override). Finally, we send the object out of memory to the ActiveX structured storage with a call to CObjectInfo::StoreObject (see
Figure 13).

Here’s how CObjectInfo::StoreObject works. A pointer to the IStorage COM interface on a storage is obtained through a call to CObjectBroker::GetObjectStorage. With the IStorage interface in hand, we open or create a COleStream­File named with the unique stream name obtained from CObjectInfo::GetStream. We create a CArchive on the COleStreamFile and dump the CDynamicObject into the archive. Finally, we clean up and free the memory where the CDynamicObject was living.

There’s another thing to notice about CObjectBroker. It uses multiple inheritance to inherit from both CObject and CSubject. Since CObjectBroker contains all of our dynamic objects, CObjectBroker itself will be an interesting subject to many observers. As dynamic objects enter and leave the object broker, CObject­Broker uses CSubject::­­Notify­Observers to let registered observers know about completed additions, pending removals, completed removals, and renamed objects.

We’ll see how to handle notifications from the object broker a little later. The important thing to recognize now is that, just by inheriting from CSubject, CObject­Broker is able to broadcast notifications in a very generic way. It can do this without having to know anything about whom the observers will be, other than that they are derived from CObserver. This means you write the object broker code once, compile it, and forget it. The Observer pattern leads to the creation of an object broker that is independent of any implementation details associated with objects to which it must send change notifications. Undesirable object dependencies are eliminated. To create an object that needs to know about the object broker, inherit from CObserver, register with the object broker as an observer, and it all just works.

So far, so good. But how do you get to an existing dynamic object from CObjectBroker? The process is summarized in Figure 14. CObjectBroker::GetObjectInfoByKey, along with the key returned from CObjectBroker::Add, returns a pointer to the CObjectInfo associated with our dynamic object. Call CObjectInfo::Get­Object (see Figure 13) to get a pointer to a CDynamicObject, the base class for the dynamic object. If the object is already alive, GetObject simply increments a reference count and returns the pointer to the living object. Otherwise, we again use MFC’s dynamic object creation facility to create the object, this time through serialization from a temporary CArchive object created using a COleStreamFile in our structured storage. We again give you a hook to do whatever processing may be appropriate via a call to the virtual function CDynamicObject::OnSerializedObjectFrom­Archive, which you can override.

Figure 14 Getting a Dynamic Object from CObjectBroker

CObjectBroker::GetObjectStorage gets a pointer to the IStorage COM interface for a storage in our application’s compound file. Now here’s the million dollar question: how does m_pRootStorage in CObjectBroker get set? The simple answer is that the document object, in our case CObjectDoc, needs to set it through a call to CObjectBroker::SetRoot­Storage (see Figure 13), but it’s a little more complicated than that. CObjectDoc is derived from the MFC COle­Document. If you go snooping around the MFC header file for COleDocument, you will find a protected member variable called m_lpRootStg. If you call COleDocu­ment::Enable­CompoundFile in the constructor for your document, your app’s file will be a compound file and m_lpRootStg will point to a valid IStorage interface for the root storage. Seems simple enough, but there’s a fly in the ointment. When a new document is opened, m_lpRootStg gets set to a temporary storage. The first time you save the document, MFC suddenly changes m_lpRootStg to a permanent storage in the actual file. To get around this issue, COb­ject­Bro­ker::
SetRoot­Storage needs to be called from both COb­ject­­­­Doc::
OnNewDocument and CObjectDoc::Serialize (see Figure 13).

CObjectBroker::SetRootStorage checks to see if the incoming pointer pRootStorage is the same as the stored pointer m_pRootStorage. If it is, everything is cool and we just return. If m_pRootStorage is NULL, we need to create a storage for our dynamic objects and then set m_pRoot­Storage accordingly. Pretty straightforward. The weird and somewhat confusing condition occurs if m_pRootStorage has already been set and pRootStorage is different. This is the clue that we are doing an initial save of the document and both pointers point to valid storagesæthe temporary one and the permanent one. For this weird case, we need to move the storage we’re using for our dynamic objects from the temporary one to the permanent one.

Now let’s turn our attention to CDynamicObject, the base class for our dynamic objects. As with ActiveX COM objects, there’s one rule you must always abide by when using CDynamicObjects. When you are done with the CDynamic­Object, you must call CDynamicObject::Release. Release decrements the object’s reference count. If the reference count goes to zero, Release calls CObject­Info::StoreObject, which we discussed earlier. We need to be really careful. StoreObject will delete the CDynamic­Object. This has the same effect as deleting this pointer. Just be careful not to access any of the object’s memory after the call to StoreObject—which is something that is easy to overlook. This is why we return zero rather than m_nRefCount:

ULONG CDynamicObject::Release()

{

if (--m_nRefCount > 0)

return m_nRefCount;

else

{

m_pObjectInfo->StoreObject(TRUE);

return 0;

}

}

Dynamic Object Pattern

Let’s move on to the Dynamic Object design pattern, which provides a generic, cookbook approach to structuring classes and using dynamic objects in any application. The pattern coordinates the actions of eight participants (see Figure 15):

• CViewBroker (or some other class responsible for managing views)
  
  
• CMultiDocTemplateEx
  
  
• MFC Framework
  
  
• KindOfCViewAndCObserver (a class inheriting from CView and CObserver)
  
  
• CObjectBroker
  
  
• CObjectInfo
  
  
• KindOfCDynamicObjectAndCSubject (a class inheriting from CDynamicObject and CSubject)
  
  
• KindOfCDocument (a class inheriting from CDocument)

Figure 15 Dynamic Object Pattern

Keep in mind that while the pattern is described using the CViewBroker class, the pattern can be used in other con­texts as long as some class that is responsible for view management performs the CViewBroker duties described here.

The first part of the pattern handles the actions required to open a view on a dynamic object. This is a significant task since the application has no knowledge of either the view or the dynamic object that will be created. The pattern begins when CViewBroker calls CMultiDocTemplateEx::Create­New­Frame. CreateNewFrame instantiates a new KindOfC­­ViewAndCObserver. Following the call to CreateNewFrame, CViewBroker calls CWnd::SendMessage to send a WM_
OBJECTINFO custom message to the newly created KindOf­C­ViewAndCObserver. A pointer to an ObjectInfoMessage structure is passed along with the message. This structure contains the unique key for the dynamic object associated with the view being opened, along with a pointer to the object broker. The call to SendMessage triggers a call to KindOfCViewAndCObserver::On­ObjectInfo. Since a
pointer to the object broker was passed with the message, OnObject­Info can call CObjectBroker::­Get­Object­InfoByKey and then CObjectInfo::GetObject to obtain a pointer to the dynamic object.

Recall that the call to GetObject will cause the dynamic object to move from the application’s compound file into active memory if it isn’t already there. Also, remember that a call to GetObject carries with it an obligation to call CDynamicObject::Release when we are finished with the dynamic object. With the pointer to the dynamic object in hand, OnObjectInfo can call CSubject::AttachToSubject to register KindOfCViewAndCObserver as an observer of Kind­OfCDynamicObjectAndCSubject. Finally, CView­Broker calls CMultiDocTemplate::InitialUpdate­Frame, which will result in a call to KindOfCViewAndC­Obser­ver::OnInitialUpdate and KindOfCViewAndC­Observer::­OnUpdate. These functions need to do whatever is necessary to refresh the view for the first time as indicated in the pattern by the call to KindOfCViewAndCObser­ver::RefreshViewAsRequired. RefreshViewAsRequired is a generic function name that you will probably change to fit your own context.

The second part of the pattern handles the actions required for KindOfCViewAndCObserver to handle graphical user interface (GUI) events. The MFC framework will trigger a call to KindOfCViewAndCObserver::OnGUIEvent as a result of a GUI event such as pressing a button, changing a selection in a list box, or handling a mouse click. OnGUIEvent is another generic function name that will change depending on the context of the particular GUI event. OnGUIEvent calls KindOfCDynamicObject­AndCSubject::ChangeState (another generic function name) to change the state of the dynamic object as required by the GUI event. Then OnGUIEvent calls CDocument::Set­ModifiedFlag to mark the document as dirty and CDocu­ment::UpdateAllViews to tell all views to update themselves as required.

Now, let’s back up and look again at KindOfCDyna­micObjectAndCSubject::ChangeState. Note that, after ChangeState performs its designated function, it calls CSubject::NotifyObservers to broadcast a change notification to all registered observers of KindOfCDynamic­ObjectAndCSubject. There could be a very long list of objects and views registered as observers, and the result could be a very complex cascade of events. Don’t worry about all of thatætrust the pattern and everything will work. The call to NotifyObservers will cause the CObserver::SubjectChanged function to be called for each registered observer. KindOfCViewAndCObserver::­Subject­Changed calls KeepTrackOfChanges (another generic function name) which should keep track of the changes required to refresh the CView during the next CView::OnUpdate call, which results from the call to CDocument::Update­AllViews discussed previously. KindOfCViewAndCOb­server::­OnUpdate calls KindOf­CView­And­C­­Observer::­­
Re­fresh­View­AsRequired to accomplish the necessary changes to the view.

The final part of the pattern concerns the actions required when our KindOfCViewAndCObserver is destructed. We need to call CSubject::DetachFromSubject to unregister the KindOfCViewAndCObserver as an observer of CDyna­mic­ObjectAndSubject. Finally we must call CDynamic­Object::Release, which decrements the reference count on the dynamic object and dismisses the object from memory back to the compound file if the count reaches zero.

You may be wondering why we decided to send the WM_OBJECTINFO message to the view rather than providing a base class for the view and putting a member function in the base class that communicates the dynamic object information to the view. Since we don’t know what kind of view will be used, we didn’t want to provide several different base classesæone for each view class in MFC. This approach would require using runtime type information to get the class type and then making a call to the appropriate class, which is a very messy way to do things. So we picked the lesser evil of sending a custom message.

The Dynamic Object pattern probably seems a bit complicated at first glance, but handling multiple views on interdependent objects is not trivial. If you plug into the cookbook design of the Dynamic Object pattern, everything will work. This will become more evident as we move on and look at our three example DLLs. The pattern will be rigorously applied to each one. You will see how extensible the pattern is and how using the pattern becomes a mechanical process that really isn’t all that complicatedæconsidering what it accomplishes.

Dynamic Objects and Views

Our first example DLL, OVRotor.dll, demo­nstrates how a view should interact with a dynamic object and how to handle persistent data for 
dyna­mic objects. OVRo­tor.dll houses a dynamic object class called CRotor, a base class for the dynamic object called CGeneric­Rotor, and an associated view class called CRotorView (see Figures 16 and 17). CRotor knows how to draw several different rotors on a device context. The user’s rotor selection is persistent data.

Figure 16 ObjectView Hosting a CRotor Dynamic Object

Figure 17 CRotor, CGenericRotor, and CRotorView

Recall that a function called ClassInfo must be exported by each DLL housing a dynamic object. ClassInfo for OV­Ro­tor.dll looks a lot like Class­Info did for Simple.dll (see Figure 18). Of course, the class ID, class category, and run­time classes are different.

Figure 18 OVRotor.dll

ClassInfo Function Exported from OVRotor.dll

extern "C" void WINAPI ClassInfo(CLSID& clsidClassID,

CLSID& clsidClassCategory, CString& csDescription,

CRuntimeClass*& pObjectClass, CRuntimeClass*& pFrameClass,

CRuntimeClass*& pViewClass)

{

// ID: {4423E281-664E-11d0-8945-2AFFD5000000}

CLSID clsidID = { 0x4423e281, 0x664e, 0x11d0,

{ 0x89, 0x45, 0x2a, 0xff, 0xd5, 0x0, 0x0, 0x0 } };

// CATEGORY: {A8D09C01-90C4-11d0-A264-0040052E01FC}

CLSID clsidCategory = { 0xa8d09c01, 0x90c4, 0x11d0,

{ 0xa2, 0x64, 0x0, 0x40, 0x5, 0x2e, 0x1, 0xfc } };

clsidClassID = clsidID;

clsidClassCategory = clsidCategory;

csDescription = "Rotor";

pObjectClass = RUNTIME_CLASS(CRotor);

pFrameClass = RUNTIME_CLASS(CFlexibleChildFrame);

pViewClass = RUNTIME_CLASS(CRotorView);

}

Constructor for CRotorView

CRotorView::CRotorView()

: CNSFlexFormView(CRotorView::IDD)

{

//{{AFX_DATA_INIT(CRotorView)

// NOTE: the ClassWizard will add member initialization here

//}}AFX_DATA_INIT

m_pRotor = NULL;

AddFlexConstraint(IDC_ROTORS,

NSFlexHorizontallyFixed,NSFlexExpandDown);

AddFlexConstraint(IDC_LOCATOR,

NSFlexExpandRight,NSFlexExpandDown);

}

OnObjectInfo Method of CRotorView

LRESULT CRotorView::OnObjectInfo(WPARAM wParam, LPARAM lParam)

{

ObjectInfoMessage* pObjectInfoMessage =

(ObjectInfoMessage*)(lParam);

CObjectBroker* pObjectBroker = pObjectInfoMessage->pObjectBroker;

CObjectInfo* pObjectInfo =

pObjectBroker->GetObjectInfoByKey(pObjectInfoMessage->

pszObjectKey);

ASSERT(pObjectInfo);

m_pRotor = (CRotor*)pObjectInfo->GetObject();

ASSERT(m_pRotor);

ASSERT(m_pRotor->IsKindOf(RUNTIME_CLASS(CRotor)));

m_pRotor->AttachToSubject(this);

return 1;

}

Serialize Method of CRotor

void CRotor::Serialize(CArchive& archive)

{

CDynamicObject::Serialize(archive);

if (archive.IsStoring())

{

archive << m_nSelectedRotor;

}

else

{

archive >> m_nSelectedRotor;

}

}

OnUpdate Method of CRotorView

void CRotorView::OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint)

{

if (!m_bNeedUpdate)

return;

CListBox* pRotorsList = (CListBox*)GetDlgItem(IDC_ROTORS);

for (int ii = 0; ii < m_pRotor->GetNumRotors(); ii++)

{

if ((int)pRotorsList->GetItemData(ii) ==

m_pRotor->GetSelectedRotor())

{

pRotorsList->SetCurSel(ii);

break;

}

}

Invalidate();

m_bNeedUpdate = FALSE;

}

OnSelchangeRotors Method of CRotorView

void CRotorView::OnSelchangeRotors()

{

CListBox* pRotorsList = (CListBox*)GetDlgItem(IDC_ROTORS);

int nRotor = pRotorsList->GetItemData(pRotorsList->GetCurSel());

m_pRotor->SelectRotor(nRotor);

GetDocument()->SetModifiedFlag();

GetDocument()->UpdateAllViews(NULL);

}

SelectRotor Method of CRotor

void CRotor::SelectRotor(int nIndex)

{

ASSERT(nIndex >= 0 && nIndex <= NUM_ROTORS);

m_nSelectedRotor = nIndex;

NotifyObservers(ROTOR_CHANGED,NULL);

}

SubjectChanged Method of CRotorView

void CRotorView::SubjectChanged(CSubject* pSubject,

LPARAM lHint, void* pHint)

{

ASSERT(pSubject == m_pRotor);

switch(lHint)

{

case ROTOR_CHANGED:

m_bNeedUpdate = TRUE;

break;

default:

ASSERT(FALSE);

}

}

Destructor for CRotorView

CRotorView::~CRotorView()

{

m_pRotor->DetachFromSubject(this);

m_pRotor->Release();

}

Now, let’s begin stepping through our Dynamic Object pattern and looking at the implementation of each step. We’ll begin when CView­Broker calls CMultiDocTemplate­Ex::CreateNewFrame resulting with the instantiation of a new CRotorView. All that happens in the constructor for CRotorView is the addition of constraints for the flexible view behavior in the CNSFlexFormView base class (see Figure 18). Note how easy it is to add the resizing behavior. Well-designed, extensible architectures can let you add a lot of functionality by inserting new classes in the inheritance chain.

Next, CViewBroker will send the WM_OBJECTINFO message with information about the CRotor dynamic object that our view references. Again, the code looks the same
as for Simple.dll (see Figure 18). The key difference this time is that CRotorView uses multiple inheritance to inherit from both CNSFlexFormView and CObserver. Inheriting from CObserver will allow us to be informed about changes to the CRotor dynamic object. After we get hold of the CRotor dynamic object through a call to CObjectInfo::
GetObject, we call CSubject::AttachToSubject to register as an observer.

If this is the first view being opened on the CRotor dynamic object, the dynamic object will not be in memory, so GetObject will instantiate a new CRotor and then call CRotor::Serialize to bring in the persistent data (see Figure 18). The Serialize function is the one you are familiar with, but recall that the object broker is in the background, silently making the compound file look like a CArchive.

The last thing CViewBroker does in opening a view on a CRotor is to call CMultiDocTemplate::InitialUpdateFrame. This results in a call to CRotorView::OnInitialUpdate, which results in a call to CRotorView::OnUpdate (see Figure 18). All we do is make sure the rotor selection in the list box is set properly and then call Invalidate to force the selected rotor to be redrawn. The details of drawing the rotor are not important here, but you can check out the source code if you are interested in how it’s done.

Now we have a CRotor dynamic object and an associated CRotorView. Next, we want to see what happens on a GUI event. There’s a list box on CRotorView that allows the user to select the type of rotor graphic. When the user changes the selection in the list box (see Figure 18), CRotorView::
OnSelchangeRotors gets called by the MFC framework. We follow the pattern exactly. First we call CRotor::SelectRotor (analogous to the ChangeState function name in the pattern) to change the state of our dynamic object. Then we call CDocument::SetModi­fiedFlag and CDocument::
Update­AllViews.

CRotor::SelectRotor also follows the pattern exactly (see Figure 18). We change a member variable to indicate the current rotor selection, and then broadcast information about the change to registered observers through a call to CSubject::NotifyObservers.

CRotorView, a registered observer of the CRotor, will receive notification of the rotor change through CObserver::
SubjectChanged (see Figure 18). The pattern says we need to keep track of changes required to our view. For this simple case, it’s just a matter of setting the m_bNeedUpdate flag.

Recall that CRotorView::OnSelchangeRotors made a call to CDocument::UpdateAllViews. UpdateAllViews generates a call to CRotorView::OnUpdate. We’ve already looked at CRotorView::OnUpdate since it was called as part of CRotorView::OnInitialUpdate. We complete the pattern with the destructor for CRotorView (see Figure 18). Again, we follow the pattern exactly.

Now is a good time to go and play with the ObjectView code again (see Figure 16). Click the Add button on the Object Broker window to create an instance of a CRotor object. Click the View button to open a CRotorView on the CRotor object. With a CRotorView window activated, click on the Window | New Window command or hit the toolbar button and open another view on the object. Notice how all windows get updated as you change the selected graphic. Resize a CRotorView window and notice how the controls are intelligently repositioned as a result of using the CNSFlexFormView. If you click the Remove button on the Object Broker window while the Rotor window is open, all the Rotor windows close and the dynamic object is permanently removed. Remember, all of this behavior was added without touching the ObjectView application. Also keep in mind that the CRotor objects are silently shuffling between memory and the application’s compound file as required, and persistent object data is getting saved appropriately. The user and developer never notice any of this. In fact, the only thing the user will ever notice is that memory usage is low and saving files is quick—even when working with numerous large objects.

Interdependencies

Our second example DLL, OVRotorDri­ver.dll, demonstrates how to handle object interdependencies—a common source of problems in many applications. We’re going to create a new object that tells the rotor object from the first example to draw itself at timed intervals and specific orientations. In other words, we’re going to spin the rotor. OVRotor­Driver.dll houses a dynamic object class called CRotorDriver, an associated view class called CRotorDriver­View, and a popup dialog called CProp­ertiesDlg (see Figures 19 and 20). CRotorDriver knows how to reference a CGenericRotor and make it spin on a thread of execution. The references to CGenericRotor and several other parameters are persistent data.

Figure 19 ObjectView Hosting a CRotor Driver Dynamic Object

Figure 20 CRotorDriver and CRotorDriverView

Again, the Dynamic Object pattern makes handling object interdependencies simple and mechanical. CRotorDriver and CRotorDriverView are very similar to CRotor and CRotorView from our first example. The added twist is the reference to CGenericRotor, which makes a CRotorDriver dependent on an instance of a CGenericRotor.

Recall that CObjectInfo::GetObject generates a call to CDynamicObject::Serialize to load persistent data into the object. The interesting thing to note about CRotor­Driver::Serialize is the ser­ialization of m_csRotorKey, the key for the referenced CGenericRotor object (see
Figure 21).

Figure 21 OVRotorDriver.dll

Serialize Method of CRotorDriver

void CRotorDriver::Serialize(CArchive& archive)

{

if (archive.IsStoring())

{

archive << m_bRotorIsGoing;

archive << m_nRotationIncrement;

archive << m_nUpdateInterval;

archive << m_nRotorPosition;

archive << m_bRotateClockwise;

archive << m_csRotorKey;

}

else

{

archive >> m_bRotorIsGoing;

archive >> m_nRotationIncrement;

archive >> m_nUpdateInterval;

archive >> m_nRotorPosition;

archive >> m_bRotateClockwise;

archive >> m_csRotorKey;

}

}

OnSerializedObjectFromArchive Method of CRotorDriver

void CRotorDriver::OnSerializedObjectFromArchive()

{

AttachToObjectBroker();

AttachToRotor();

m_pTriggerThreadInfo->m_nUpdateInterval = m_nUpdateInterval;

m_pTriggerThread =

AfxBeginThread(TriggerThreadProc,m_pTriggerThreadInfo);

ASSERT(m_pTriggerThread);

if (m_bRotorIsGoing)

SetEvent(m_pTriggerThreadInfo->m_hEventStartInterval);

}

AttachToObjectBroker Method of CRotorDriver

void CRotorDriver::AttachToObjectBroker()

{

GetObjectBroker()->AttachToSubject(this);

}

AttachToRotor Method of CRotorDriver

void CRotorDriver::AttachToRotor()

{

DetachFromRotor();

CObjectInfo* pObjectInfo =

GetObjectBroker()->GetObjectInfoByKey(m_csRotorKey);

if (pObjectInfo)

{

m_pRotor = (CGenericRotor*)pObjectInfo->GetObject();

m_pRotor->AttachToSubject(this);

}

else

{

m_csRotorKey.Empty();

}

}

DetachFromRotor Method of CRotorDriver

void CRotorDriver::DetachFromRotor()

{

if (m_pRotor)

{

m_pRotor->DetachFromSubject(this);

m_pRotor->Release();

m_pRotor = NULL;

}

}

SubjectChanged Method of CRotorDriver

void CRotorDriver::SubjectChanged(CSubject* pSubject,

LPARAM lHint, void* pHint)

{

if (pSubject == m_pRotor)

{

switch(lHint)

{

case ROTOR_CHANGED:

NotifyObservers(ROTOR_DRIVER_ROTOR_CHANGED,NULL);

return;

}

ASSERT(FALSE);

}

if (pSubject == GetObjectBroker())

{

switch(lHint)

{

case OBJECT_BROKER_ABOUT_TO_REMOVE_OBJECT:

if (m_csRotorKey == *((CString*)pHint))

SetRotorKey("");

return;

case OBJECT_BROKER_ADDED_OBJECT:

case OBJECT_BROKER_REMOVED_OBJECT:

case OBJECT_BROKER_RENAMED_OBJECT:

return;

}

ASSERT(FALSE);

}

ASSERT(FALSE);

}

SetRotorKey Method of CRotorDriver

void CRotorDriver::SetRotorKey(LPCSTR pszRotorKey)

{

m_csRotorKey = pszRotorKey;

AttachToRotor();

NotifyObservers(ROTOR_DRIVER_SELECTED_ROTOR_CHANGED,NULL);

}

Destructor for CRotorDriver

CRotorDriver::~CRotorDriver()

{

DWORD dwExitCode;

if (GetExitCodeThread(m_pTriggerThread->m_hThread, &dwExitCode) &&

dwExitCode == STILL_ACTIVE)

{

SetEvent(m_pTriggerThreadInfo->m_hEventKillTriggerThread);

SetEvent(m_pTriggerThreadInfo->m_hEventStartInterval);

WaitForSingleObject(

m_pTriggerThreadInfo->m_hEventTriggerThreadKilled,

INFINITE);

}

delete m_pTriggerThreadInfo->m_pThreadMessageWnd;

delete m_pTriggerThreadInfo;

DetachFromRotor();

DetachFromObjectBroker();

}

DetachFromObjectBroker Method of CRotorDriver

void CRotorDriver::DetachFromObjectBroker()

{

GetObjectBroker()->DetachFromSubject(this);

}

After calling CDyna­mic­Object::Serialize, COb­ject­Info::Get­­Object calls
CDyna­mic­Object::OnSerial­ized­Object­From­Archive, which is overridden in CRo­torDriver (see Figure 21). Note that CRotorDriver::On­SerializedObject­From­Archive makes calls to CRotorDriver::
Attach­To­ObjectBroker and CRotorDriver::Attach­ToRotor. This is also where we launch a new thread of execution to make the rotor spin. We decided to throw threads into the example just for fun. Threads are not important to the main ideas here, so we won’t dive into that subject. But you can look at the code that accompanies the article if you are interested in seeing the details.

CRotorDriver::Attach­To­ObjectBroker simply calls CSubject::AttachToSubject to register as an observer of CObjectBroker (see Figure 21). CRotorDriver::AttachToRotor does the real work of turning m_csRotorKey, the key to the referenced object, into m_pRo­tor, a pointer to a living, breathing CGenericRotor object (see Figure 21). First, AttachToRotor calls CRotor­Driver::DetachFromRotor to make sure we unregister as an observer of CGenericRotor and release any CGeneric­Rotor object to which we may have already been attached. We call CObjectBroker::
GetObjectInfoByKey to get the CObjectInfo associated with m_csRotorKey, and then call CObjectInfo::­GetObject to get a pointer to the CGen­eric­Rotor object. Finally, we call CSubject::AttachToSub­ject to register as an observer of the CGenericRotor object. It’s really that simple to handle each object interdependency. It doesn’t matter how numerous or complicated they get. Just be careful and do each one the same way.

CRotorDriver::SubjectChanged is also a little more interesting than before (see Figure 21). One of the nice things about the implementation of SubjectChanged is that it passes us a pointer to the CSubject that has changed. CRotorDriver is watching two subjects: the CGenericRotor object and the CObjectBroker object. Since we’re holding a reference to another object, we need to know if a higher authority—the user—wants it deleted. If so, we have to release our reference. We check to see if pSubject is the CObjectBroker; if it is, we check for the OBJECT_BROKER_
ABOUT_TO_REMOVE_OBJECT hint and call CRotor­Driver::SetRotor­Key with a null string. CRotorDriver::
Set­RotorKey sets the value of m_csRotorKey, calls CRotor­Driver::AttachToRotor, and notifies any of its observers through a call to CSubject::NotifyObservers (see Figure 21).

In the destructor for CRotorDriver, we need to detach from the CGenericRotor object and CObjectBroker object. This is accomplished through calls to CRotorDriver::
DetachFromRotor and CRotorDriver::DetachFrom­Object­Broker (see Figure 21).

Run ObjectView again (see Figure 19). Click the Add button on the Object Broker window to create a rotor. Click the Add button again to create a rotor driver. Click the View button to open a view on the rotor driver. Now click the Properties button on the rotor driver and select the rotor from the dropdown list. Finally, hit the Start button and you will see it spinning. To change the appearance of the spinning rotor, open a view on the rotor and select a different rotor type. The Dynamic Object pattern makes everything work. Changes to rotors are smoothly propagated to rotor driversæand the main application never had to know anything about either one.

Interchangeable Classes

Our last example DLL, OVUserRotor.dll, demonstrates the useful concept of interchangeable classes. Interchangeable classes are a very extensible way to provide hooks for customizing applications at runtime. OVUserRotor.dll houses a dynamic object class called CUserRotor that can be used interchangeably with the CRotor class introduced in the first example (see Figure 22).

Figure 22 CRotorDriver Referencing CUserRotor

Let’s drop back to the OVRotor.dll example for a moment. CGenericRotor, a base class for CRotor, contains a single virtual function called DrawRotoræa hook for an interchangeable class. The popup dialog in the OVRotorDriver.dll example, CPropertiesDlg, includes a list of CGenericRotor objects. The list gets loaded by enumerating all the objects contained in the CObjectBroker object and loading only those objects that belong to the class category for CGeneric­Rotor objects (see Figure 23). The CUserRotor dynamic object class in our new DLL is interchangeable with a CRotor class because it inherits from CGenericRotor and its class category matches the CGenericRotor class category.

Figure 23 OVUserRotor.dll

OnInitDialog Method of CPropertiesDlg

BOOL CPropertiesDlg::OnInitDialog()

{

// ROTOR CLASS CATEGORY: {A8D09C01-90C4-11d0-A264-0040052E01FC}

CLSID clsidRotorClassCategory = { 0xa8d09c01, 0x90c4, 0x11d0,

{ 0xa2, 0x64, 0x0, 0x40, 0x5, 0x2e, 0x1, 0xfc } };

CComboBox* pRotors = (CComboBox*)GetDlgItem(IDC_ROTORS);

CObjectBroker* pObjectBroker = m_pRotorDriver->GetObjectBroker();

for (POSITION pos = pObjectBroker->GetStartPosition(); pos; )

{

CString csKey;

CObjectInfo* pObjectInfo;

pObjectBroker->GetNextAssoc(pos,csKey,pObjectInfo);

CClassInfo* pClassInfo = CClassBroker::GetClassInfo(

pObjectInfo->GetClassID());

if (pClassInfo->GetClassCategory() == clsidRotorClassCategory)

{

int nIndex = pRotors->AddString(pObjectInfo->GetName());

pRotors->SetItemDataPtr(nIndex,pObjectInfo);

if (m_pRotorDriver->GetRotorKey() == pObjectInfo->GetKey())

{

pRotors->SetCurSel(nIndex);

m_csRotorKey = pObjectInfo->GetKey();

}

}

}

pRotors->InsertString(0,"<None>");

if (pRotors->GetCurSel() == CB_ERR)

pRotors->SetCurSel(0);

CDialog::OnInitDialog();

return TRUE; // return TRUE unless you set the focus to a control

// EXCEPTION: OCX Property Pages should return FALSE

}

ClassInfo Function Exported from OVUserRotor.dll

extern "C" void WINAPI ClassInfo(CLSID& clsidClassID,

CLSID& clsidClassCategory, CString& csDescription,

CRuntimeClass*& pObjectClass, CRuntimeClass*& pFrameClass,

CRuntimeClass*& pViewClass)

{

// ID: {08EA0501-90EF-11d0-A264-0040052E01FC}

CLSID clsidID = { 0x8ea0501, 0x90ef, 0x11d0,

{ 0xa2, 0x64, 0x0, 0x40, 0x5, 0x2e, 0x1, 0xfc } };

// CATEGORY: {A8D09C01-90C4-11d0-A264-0040052E01FC}

CLSID clsidCategory = { 0xa8d09c01, 0x90c4, 0x11d0,

{ 0xa2, 0x64, 0x0, 0x40, 0x5, 0x2e, 0x1, 0xfc } };

clsidClassID = clsidID;

clsidClassCategory = clsidCategory;

csDescription = "User Rotor";

pObjectClass = RUNTIME_CLASS(CUserRotor);

pFrameClass = RUNTIME_CLASS(CFlexibleChildFrame);

pViewClass = RUNTIME_CLASS(CUserRotorView);

}

Generic dynamic object base classes provide hooks for interchanging classes at runtime. Users can create runtime classes to do virtually anything as long as they abide by whatever contracts you set up in the form of virtual functions in your base class. The new classes can have their own views or dialogs, can use the services of other objects in your application, and can serialize their data in the application’s compound file.

What About COM, ActiveX, and OLE?

Some of the design concepts we presented resemble COM, ActiveX, and OLE techniques. However, there are two things that separate our approach from other alternatives: the ability to add dynamic objects at runtime that can use the services of other objects living in the application, whether they are COM objects or C++ objects; and the ability to add dynamic views at runtime that are indistinguishable from other views in the application, from either a user or programming perspective.

COM objects like to communicate with other COM objects. A COM object added at runtime will have a tough time using the services of a C++ object living in the application. Dynamic objects allow that to happen. An interesting idea might be to wrap COM objects inside dynamic objects to get the best of both worlds.

ActiveX controls and OLE compound documents with in-place activation allow objects to interact with users, but the mechanism is quite different from a normal MFC CView. This may or may not make sense for your application. Dynamic object views allow interaction with the user without imposing any new user interface constraints and without a lot of additional code.

Conclusion

Good architectures break your code neatly into hierarchical layers that manage interdependence seamlesslyæan important consideration for large projects with multiple development teams. You’ve seen that pushing our concepts to the limit can produce code that lets you compile and link your base application without ever including header files or libraries for any dynamic objects your application will host at runtime.

The concept of dynamic runtime objects and interchangeable classes can reap huge benefits for applications that need to support user extensions. Consider, for example, an economic forecasting application. A user could code a DLL for her own economic model and drop it in at runtime. There are unlimited possibilities for scientific and engineering applications where users want to twiddle with everything.

The code we’re providing is just an example of how you can implement the ideas that we have introduced in this article. The various components we’ve presented can be customized, used alone, or used collectively. The CSubject and CObserver classes can be used by themselves to solve many types of object update problems. The CClassBroker and CObjectBroker can be used by themselves to reduce memory requirements and handle serializing object references. The CViewBroker class can be used as is or modified to fit into your application. And remember that, although we are letting the CClassBroker scan for runtime DLLs, you may choose to load classes into the CClassBroker manually. Mix and match our components to meet your own needs. You can download all of the code for ObjectView and the example runtime DLLs from MSJ’s Web site at http://www.microsoft.com/msj. u

To obtain complete source code listings, see page 5.