Explorer in the Explorer of the custom browser good assistant (2)

IObjectWithSite interface
From this high-level view of the browser helper object, a concept emerges clearly: BHO is a dynamic connection library (DLL) that attaches to a new instance of Internet Explorer and, in some cases, can be attached to instances of Windows Explorer. Such modules can be connected to the browser through the site of the container.
Typically, a field is a mediation object that is between a container and each contained object. The container manages the contained objects through it, and then makes the object's built-in functionality available. The site-based relationship between the container and the object involves implementing interfaces such as IOleClientSite at one end of the container, and implementing interfaces such as IOleObject at one end of the object. By calling the method on the IOleObject, the container makes the object aware of its hosting environment.
When a container is an Internet explorer (or Windows Explorer that supports Web), it is necessary to reduce this communication pattern to the required extent from a performance perspective. Now the object needs to implement a simpler and smaller interface called IObjectWithSite. It only provides two methods.

Table 3. IObjectWithSite Interface Definition
The only strict requirement for BHO is to implement this interface. Notice that you want to avoid returning E_NOTIMPL from the previous function. You either don't implement the interface or write the method correctly.
Writing a browser Helper object
What is more appropriate than Active Template Library (ATL) to write browser helper objects that are in-process COM service programs? Another reason to choose ATL is that it already provides a good IObjectWithSite interface by default. Also, within the predefined object types supported by the ATL COM Wizard, there is an Internet Explorer object that is exactly the BHO object type. In fact, an ATL Internet Explorer object is a simple object. That is, a COM service program that supports IUnknown and self registration plus iobjectwithsite. If you add an object like this to an ATL project and reference the Cviewsource class, you can get the following code from the wizard:
Class Atl_no_vtable Cviewsource:
Public ccomobjectrootex<ccomsinglethreadmodel>
Public Ccomcoclass<cviewsource, &clsid_viewsource>
Public iobjectwithsiteimpl<cviewsource>
Public Idispatchimpl<iviewsource, &iid_iviewsource,
&LIBID_HTMLEDITLib>
As you can see, the wizard has made this class inherit IObjectWithSiteImpl, an ATL template class that provides a basic implementation of iobjectwithsite. (see atlcom.h in the Atlinclude directory in Microsoft Visual Studio 98.) Generally, you do not need to overload the Getsite () member function. In contrast, the existing code for Getsite () often (even if not always) needs to be overridden by user requirements. In fact, ATL simply saves the IUnknown pointer to a member variable called M_spunksite.