Yesterday, I had to give some recommendations of using the browser control in windows application. The following text is submitted to the client and I’ve learned the deep hidden facts of the browser control. Below are the points of my discovery and they were extremely interesting if we dwell deep into it.
There are 2 mechanisms that are supported by .NET to make the web URLs get data into windows applications. These mechanisms use components from
· shdocvw.dll (the default WebBrowser Control which supports IE 4.0+ ) supported by ieframe.dll (the Core engine for IE 7+)
· A COM component by Microsoft as “Microsoft HTML Object Library” in the form of mshtml.dll.
These both mechanisms have their purpose defined for specific need. These two flavors are available from .NET framework, thus, they work independently from the IE installation on the application runtime machines. Hence, it doesn’t matter whether the runtime machines / client machines are installed (or) not with any version of IE.
In the majority of situations, it is better to directly host the WebBrowser rather than MSHTML. This is because the WebBrowser supports in-place navigation, history, and so on—in other words, it encapsulates the expanded capabilities of the browser.
The default WebBrowser control which inherits from WebBrowserBase is like any other control of Windows form. This WebBrowserBase Provides a wrapper for a generic ActiveX control for use as a base class by the System.Windows.Forms.WebBrowser control.
Microsoft HTML Object Library | MSHTML
One great point with MSHTML host can load and display the pages from URL or Files asynchronously. If you host MSHTML directly, you gain the use of an HTML and Cascading Style Sheets (CSS) parser and renderer, but you cannot take advantage of the browser's other capabilities.
MSHTML gives a great flexibility for the developer to customize the business need and workflow. MSHTML knows the states of URLs (or) HTML pages. Thus, when the ready state of the document changes, MSHTML calls the host's implementation of IPropertyNotifySink::OnChanged. This is a handle for implementing any piece of code in the INotifier pattern
The decision to use which methodology depends on the business need and the requirements of the user story. Thus, I recommend using
· the default WebBrowser if there implementations demands all the Browser navigation
· the MSHTML if the CSS plays a vital role in the requirement
One final point of attention from this study is the automatic event delegation possibility for the MSHTML. If there is much time, I might explore this functionality.