</TABLE>
At this point, you can compile your project, but you can do very little with it since
it does not contain interfaces, methods, or properties.
<H2><A NAME="Heading3"></A>Adding an Automation Interface to the Application</H2>
<P>To be an <I>Automation Server, </I>an application must contain at least one or
more <TT>IDispatch</TT>-based interfaces. In MFC, the <TT>CCmdTarget</TT> class is
used to implement this interface. You will use the <TT>MFCClassWizard</TT> to add
your automation interfaces to your application. From the <U>V</U>iew menu, select
the Class<U>W</U>izard menu item. Click the Add C<U>l</U>ass button, and select the
New menu item to open the New Class dialog (see fig. 3.4). <B><BR>
<BR>
</B><A HREF="Art/03/cfig4r.jpg"><B>FIG. 3.4</B></A> <I><BR>
Add a new Automation Server class using the Add C</I><CITE>l</CITE><I>ass feature
of the MFC ClassWizard.</I></P>
<P>Enter the <U>N</U>ame CTracker, and select <TT>CCmdTarget</TT> as its base class
in the <U>B</U>ase class combo box. Select the <U>A</U>utomation radio button in
the Automation radio button group. The C<U>r</U>eateable by type ID radio button
and edit field are used to define the <TT>ProgID</TT> that will be used to create
and launch the Automation Server. The human readable <TT>ProgID</TT> is used in place
of the <TT>CLSID</TT> since it is much easier to write and remember. Be careful when
defining a <TT>ProgID</TT> not to create duplicates. For your application, leave
the <TT>ProgID</TT> set to its default value. Click OK to create your new class and
add it to your application. Click OK in the MFC ClassWizard dialog to close the ClassWizard.</P>
<P>When creating a new <TT>CCmdTarget</TT> class, MFC not only creates a header and
source file with all of the appropriate information, Tracker.h and Tracker.cpp in
your case, but since you selected automation support, it also updates the ODL file
with the new <TT>Dispinterface</TT> and <TT>CoClass</TT> entries (see Listing 3.1)
of your Automation Server.</P>
<P>The <TT>Dispinterface</TT> is your primary <TT>IDispatch</TT>-based interface
and is where the ClassWizard will add your new methods and properties. The <TT>CoClass</TT>
interface identifies your class factory interface. The class factory is the part
of the application that performs the actual creation of your Automation Server when
it is necessary to do so. See the OLE and MFC documentation for more information
on class factories and their role in OLE.
<H3><A NAME="Heading4"></A>Listing 3.1 MFCSERVER.ODL--Dispinterface and CoClass ODL
Entries</H3>
<P><FONT COLOR="#0066FF"><TT>// MFCServer.odl : type library source for MFCServer.dll<BR>
// This file will be processed by the Make Type Library (mktyplib) tool to<BR>
// produce the type library (MFCServer.tlb).<BR>
[ uuid(11C82943-4EDD-11D0-BED8-00400538977D), version(1.0) ]<BR>
library MFCServer<BR>
{<BR>
importlib(&quot;stdole32.tlb&quot;);<BR>
// Primary dispatch interface for CTracker<BR>
[ uuid(11C82946-4EDD-11D0-BED8-00400538977D) ]<BR>
dispinterface ITracker<BR>
{<BR>
properties:<BR>
// NOTE - ClassWizard will maintain property information here.<BR>
// Use extreme caution when editing this section.<BR>
//{{AFX_ODL_PROP(CTracker)<BR>
//}}AFX_ODL_PROP<BR>
methods:<BR>
// NOTE - ClassWizard will maintain method information here.<BR>
// Use extreme caution when editing this section.<BR>
//{{AFX_ODL_METHOD(CTracker)<BR>
//}}AFX_ODL_METHOD<BR>
};<BR>
// Class information for CTracker<BR>
[ uuid(11C82947-4EDD-11D0-BED8-00400538977D) ]<BR>
coclass TRACKER<BR>
{<BR>
[default] dispinterface ITracker;<BR>
};<BR>
//{{AFX_APPEND_ODL}}<BR>
};</TT></FONT></P>
<P>Even though the MFC ClassWizard added the new interface to the server, it did
not expose the interface to the outside world. Basically, what you have right now
is an Automation Server that cannot be created by any application. Not very useful.</P>
<P>All ActiveX components are created through an object known as a class factory.
MFC defines the class <TT>COleObjectFactory</TT> for its class factory support. You
do not add the <TT>COleObjectFactory</TT> class directly to your server implementation;
instead, you need to use two macros defined by MFC: <TT>DECLARE_OLECREATE</TT> and
<TT>IMPLEMENT_OLECREATE</TT>.</P>
<P>In the Project Workspace, select the ClassView tab. Expand the class list, and
double-click the <TT>CTracker</TT> class to open the Tracker.h file. Add the macro
<TT>DECLARE_OLECREATE</TT> to your class definition as in Listing 3.2. The macro
takes a single parameter, <TT>CTracker</TT>, which is your class name.
<H3><A NAME="Heading5"></A>Listing 3.2 TRACKER.H--Add the Class Factory Support with
the Macro DECLARE_OLECREATE</H3>
<P><FONT COLOR="#0066FF"><TT>. . .<BR>
// NOTE - the ClassWizard will add and remove member functions here.<BR>
//}}AFX_DISPATCH<BR>
DECLARE_DISPATCH_MAP()<BR>
DECLARE_INTERFACE_MAP()<BR>
DECLARE_OLECREATE(CTracker)<BR>
};</TT></FONT></P>
<P>Next in the Project Workspace window, select the FileView tab, expand the Source
Files list, and double-click the Tracker.cpp entry to open the file. Add the macro
<TT>IMPLEMENT_OLECREATE</TT> to your source file (see Listing 3.3). The <TT>IMPLEMENT_OLECREATE</TT>
macro takes three parameters: the class name, the <TT>ProgID</TT> that is used to
create the server, and the <TT>CLSID</TT> of the <TT>CoClass</TT> interface, as defined
in your ODL file. When the ODL file was created by the AppWizard, a <TT>CLSID</TT>
was generated for the type library. When the ClassWizard added the <TT>CTracker</TT>
class, it too created new <TT>CLSID</TT>s; one for the <TT>Dispinterface</TT> and
the other for the <TT>CoClass</TT>.
<H3><A NAME="Heading6"></A>Listing 3.3 TRACKER.CPP--Add the Class Factory Implementationwith
the IMPLEMENT_OLECREATE Macro</H3>
<P><FONT COLOR="#0066FF"><TT>. . .<BR>
// {11C82946-4EDD-11D0-BED8-00400538977D}<BR>
static const IID IID_ITracker =<BR>
{ 0x11c82946, 0x4edd, 0x11d0, { 0xbe, 0xd8, 0x0, 0x40, 0x5, 0x38, 0x97, 0x7d } };
<BR>
BEGIN_INTERFACE_MAP(CTracker, CCmdTarget)<BR>
INTERFACE_PART(CTracker, IID_ITracker, Dispatch)<BR>
END_INTERFACE_MAP()<BR>
IMPLEMENT_OLECREATE(CTracker, _T(&quot;MFCServer.Tracker&quot;), 0x11C82947, 0x4edd,
0x11d0, 0xbe, 0xd8, 0x0, 0x40, 0x5, 0x38, 0x97, 0x7d)<BR>
. . .</TT></FONT></P>
<P>Your server implementation is now class factory enabled, which allows it to be
created by other applications. Before another application can create the server,
however, OLE has to know where to find the server, which is done through the system
registry. All ActiveX components that are publicly available to other applications
must support registration and must create valid registry entries.
<H2><A NAME="Heading7"></A>Registry</H2>
<P>ActiveX components have one or more registry entries that are used to describe
various aspects of the application and how it can be used. The registry is critical
to the successful launching and using of ActiveX components.
<H3><A NAME="Heading8"></A>Server Registration</H3>
<P>Local servers rely on command-line options for registration support. It is the
responsibility of the local server developer to check for the correct command-line
option and take the appropriate action. 
<TABLE BORDER="1" WIDTH="100%">
	<CAPTION><B>Table 3.2 </B><SPACER TYPE="HORIZONTAL" SIZE="10"><B>Local Server Command-Line
		Options for Registration Support</B></CAPTION>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP"><B>Command-Line Option</B></TD>
		<TD ALIGN="LEFT" VALIGN="TOP"><B>Description</B></TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP"><TT>R</TT></TD>
		<TD ALIGN="LEFT" VALIGN="TOP">Register all components.</TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP"><TT>U</TT></TD>
		<TD ALIGN="LEFT" VALIGN="TOP">Unregister all components.</TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP"><TT>S</TT></TD>
		<TD ALIGN="LEFT" VALIGN="TOP">Perform registration in silent mode and do not display confirmation dialogs, indicating
			success. Error messages should still be displayed. This option can be combined with
			<TT>R</TT> or <TT>U</TT>.</TD>
	</TR>
</TABLE>
<BR>
<BR>
All inproc ActiveX components expose registration support via two exported functions:
<TT>DllRegisterServer</TT> and <TT>DllUnregisterServer</TT>.</P>
<P>The MFC AppWizard will automatically add the <TT>DllRegisterServer</TT> function
to the main application file of a project when it is created. The registration of
all of the components contained in the application should be performed in this function,
with each ActiveX component being responsible for its own registration support.</P>
<P>Registration support is handled automatically by the <TT>COleObjectFactory</TT>
class. Even though you may not be aware of it, the <TT>COleObjectFactory</TT> class
contains a singly linked list that is used to keep track of all of the <TT>COleObjectFactory</TT>
classes implemented in a single application. The linked list is a static member,
which means that all instances of the class share the same class factory list. <TT>COleObjectFactory</TT>
also contains a static function, <TT>UpdateRegistryAll</TT>, that will cycle through
the list of <TT>COleObjectFactory</TT> classes, instructing each to register themselves.
<H3><A NAME="Heading9"></A>Server Unregistration</H3>
<P>The MFC AppWizard does not add the exported function, <TT>DllUnregisterServer</TT>,
to a project when it is created. This is probably due to an inherent limitation in
MFC. The MFC group apparently did not feel it was necessary to add unregistration
support to the basic MFC <TT>COleObjectFactory</TT> class. This is very interesting
since all of the Microsoft logo requirements indicate that all applications that
are installed and registered must also uninstall and unregister themselves in order
to qualify for the logo.</P>
<P>To support server unregistration, you would have to add the exported function,
<TT>DllUnregisterServer</TT> and call the static function <TT>COleObjectFactory::UpdateRegistryAll</TT>
passing <TT>FALSE</TT> as the parameter.</P>
<P>The actual unregistration code requires more work. We didn't include the unregistration
code as a part of the sample code, but the implementation is straightforward and
is outlined here. The first step is to create a new class that inherits from <TT>COleObjectFactory</TT>,
and override the virtual function, <TT>UpdateRegistry</TT>. Check the parameter that
is passed to the function, and based on its value, call the appropriate registration
and unregistration code. MFC provides a basic registration helper function, <TT>AfxOleRegisterServerClass</TT>,
but does not define a companion helper function for unregistration. Searching the
source files in MFC reveals a complete set of helper functions for the registry,
but unfortunately they are not accessible from anything but an MFC-implemented ActiveX
control. Since nothing is available from MFC, you are required to implement the registry
updating code yourself. Remember to remove all of the registry entries that the server
created: the <TT>ProgID</TT>, the <TT>CLSID</TT>, and the type library.
<H2><A NAME="Heading10"></A>Sample Server Support Code</H2>
<P>Since your <I>sample server </I>is used to output data to a file, you first need
to add some support code to your application before adding its methods and properties.</P>
<P>Listing 3.4 shows the changes and additions that have been made to the class header
file. A set of member variables was added for storing the file handle and timer information
that will be used throughout the server implementation.
<H3><A NAME="Heading11"></A>Listing 3.4 TRACKER.H-- Sample Server Support Code Added
to the Header File</H3>
<P><FONT COLOR="#0066FF"><TT>. . .<BR>
DECLARE_OLECREATE(CTracker)<BR>
protected:<BR>
FILE * m_fileLog;<BR>
long m_lTimeBegin;<BR>
long m_lHiResTime;<BR>
long m_lLastHiResTime;<BR>
};</TT></FONT></P>
<P>The next step is to update the source file for the class. Add the include file
mmsystem.h to the Tracker.cpp file (see Listing 3.5). This is for the timer functions
that you are taking advantage of in the sample server implementation.</P>
<P>The constructor and destructor of the server have also been updated. When using
OLE in MFC applications, you must always lock the application in memory by calling
the method <TT>AfxOleLockApp()</TT>,<TT> </TT>which ensures that the application
will not be unloaded from memory until the reference count reaches zero. This step
is critical and must be in all MFC-based servers.</P>
<P>Next you create a high resolution timer and store its current value in your member
variables. The timer is useful for determining the number of milliseconds that have
passed since the last method call was made. The timer output is great for tracking
the performance of a particular action or set of actions.</P>
<P>You then get the current date and create a filename with the format YYYYMMDD.tracklog.
After successfully opening the file, you output some start-up data to the file and
exit the constructor.</P>
<P>The destructor does the exact opposite of the constructor. If there is a valid
file handle, you write some closing information to the file and close it. Next you
terminate the timer. Remember to call the function <TT>AfxOleUnlockApp()</TT> to
allow the application to be removed from memory.
<H3><A NAME="Heading12"></A>Listing 3.5 TRACKER.CPP--Updated Source File</H3>
<P><FONT COLOR="#0066FF"><TT>. . .<BR>
#include &quot;Tracker.h&quot;<BR>
// needed for the high resolution timer services<BR>
#include &lt;mmsystem.h&gt;<BR>
#ifdef _DEBUG<BR>
#define new DEBUG_NEW<BR>
#undef THIS_FILE<BR>
static char THIS_FILE[] = __FILE__;<BR>
#endif<BR>
/////////////////////////////////////////////////////////////////////////////<BR>
// CTracker<BR>
IMPLEMENT_DYNCREATE(CTracker, CCmdTarget)<BR>
CTracker::CTracker()<BR>
{<BR>
EnableAutomation();<BR>
// make sure that the application won't unload until the reference count is <BR>
::AfxOleLockApp();<BR>
// setup our timer resolution<BR>
m_lTimeBegin = timeBeginPeriod(1);<BR>
m_lHiResTime = m_lLastHiResTime = timeGetTime();<BR>
// get the current date and time<BR>
CTime oTimeStamp = CTime::GetCurrentTime();<BR>
CString cstrFileName;<BR>
// create a file name based on the date<BR>
cstrFileName.Format(_T(&quot;%s.tracklog&quot;), (LPCTSTR) <BR>
oTimeStamp.Format(&quot;%Y%m%d&quot;));<BR>
// open a file<BR>
m_fileLog = fopen(cstrFileName, _T(&quot;a&quot;));<BR>
// if we have a file handle<BR>
if(m_fileLog)<BR>
{<BR>