Reusing Browser Technology - Driller (MFC)

Description: There are two Drill samples, both do the same thing, however one is written using MFC and the other is written using Visual Basic.

The Driller (MFC) sample is an MFC based control host, that hosts the WebBrowser Control as part of another application.

The buttons and address input are supplied by the hosting application and commands are sent to the WebBrowser control on the form. Entering a URL in the address field on the form will result in the WebBrowser control navigating to that page.

Additionally, the Drill samples show how a hosting application can "drill" into the WebBrowser control and investigate the loaded HTML document. In this case the host walks the ALL collection of the document object of the loaded html page using Dynamic HTML and populate a list box with each element encountered.

More Details

The functionality of drilling into the document hosted and listing the tags found in the listbox is discussed in the readme file for Driller.

The Driller sampler adds additional functionality by providing extra control through the implementation of the IDocHostUIHandler interface. This sample shows how this interface can be used to control the context menus and extend the Dynamic HTML Object Model.

Browser/Platform Compatibility

This sample is supported in Internet Explorer 4 and Internet Explorer 5.
Usage

The Context menus that appear as standard for a right mouse click are disabled within the Driller sample. This is achieved by returning S_OK from the ShowContextMenu method of the IDocHostUIHandler interface, indicating that the host has handled the call and the IE components need not perform the standard processing.
The Dynamic HTML Object Model is also extended in the Driller sample by providing an IDispatch interface to the getExternal method of the IDocHostUIhandler interface. This IDispatch is used whenever the script within the HTML document refers to window.external; whatever follows this will be handed to the GetIDsof Names member function of the IDispatch interface to be resolved. This can be seen by loading the extend.htm file supplied into Driller and pressing the Extend button.

To implement the IDocHostUIHandler, the client site needs to implement the interface. In MFC, the class COleControlSite encapsulates the client site. In this example we are subclassing MFC, a class CCustomControlSite, is derived from COleControlSite and CCustomControlSite implements IDocHostUIHandler. To hook in the CCustomControlSite, a class CCustomOccManager is derived from COccManager. Subclassing COccManager and COleControlSite in such a manner is implementation specific to MFC. So, if future versions of MFC change the implementation of COleControlSite or COccManager, this sample (and your code if you use this technique) might not work. We are looking at possible ways to have MFC expose the client site for customization. If in future MFC does expose the client site, then we will modify this sample to use that functionality.

If you are using this sample to design your code please be advised that you may have to change your code in the future.

When compiling 'Driller' make sure you do not include the Headers and Libs in your directory path!

It is possible that this sample will not compile because an include directory has not been identified. The program looks for the file called occimpl.h. Prepended to the header file is the directory where that file was located on the test machine. This may be different than most users. The solution is to delete the prepended directory and under Project->Settings, go to the C/C++ tab, look under Preprocessor and then add the Include directory to the additional include directories. An example of what that might look like is: c:program filesdevstudiovcmfc.