Paul Fallon's WebLog : The Web Browser control in Whidbey

Microsoft.com Home

Site Map

Blogs Home

Paul Fallon's WebLog

From Ireland: a little bit of this and a little bit of that

The Web Browser control in Whidbey - Part 1

When you look at all of the good stuff that is in Visual Studio 2005 (i.e. Visual Studio Whidbey), its hard not to say WOW!! there is just so much good stuff in there. Things like Visual Studio Team System, the new productivity enhancements, ASP.NET V2, System.Transactions, MSBuild etc.. and they are all fantasic new features/products and I would encourage you to have a look. But there are lots of little details in Visual Studio 2005 that desire a mention as well. Take the humble, yet very powerful Web Browser control that we all know and love :).

Before the days of .NET, when developers wanted to render HTML pages within their applications, they would reference the Web Browser control, Drag'n'Drop the WebBrowser control onto a VB Form (or a C++ form) and use the standard WebBrowser interface and its 8+ methods (i.e. GoBack, GoForward, GoHome, GoSearch, Navigate, Refresh, Refresh2 and Stop). With the current versions of .NET (i.e V1.0 and V1.1) things are pretty much the same, with the obvious exception of the fact that you are going through COM Interop.

More often than not, when I see people reuse the Web Browser control in a project a few things are missed. The most notable of these would be the disabling of the context menu and keyboard accelerators. I would say that these 2 particular aspects of the control always need to be disabled in a custom project that is reusing the control. What do you think? Is it acceptable to allow the end-user to have the ability to right mouse click on a web page and click on "View Source" or go "Back"? For me it generally is not!! And most people that are reusing the browser control also have this requirement, but for different reasons its doesn't get implemented or it gets implemented in a fairly fragile & time intensive way (by having scripts in each web page capturing the right mouse click for example).

The cleanest way of controling these and many more aspects of the Web Browser control is through implementing the IDocHostUIHandler interface, but alas you can't do this in VB6. So, how do you do implement it? Will the only way in the pre .Net days was through VC++ and there is a sample of how it can be done up on the MS Support web site. Because you really could only do this in C++, is quite possibly the main reason that very few projects that I have seen actually took full control over the Web Browser control and people lived with the fact that their applications may be broken by some of the browser features not being disabled etc.. but this is where Whidbey is going to makes things V easy for you :D

Now with Visual Studio 2005, when you have the Windows Forms design opened and you have the Windows Forms Toolbox open, you will see a .NET Component called "WebBrowser". Ok, so its still reusing the same Web Browser control and its now done through the a managed wrapper of the Web Browser that is part of the System.Windows.Forms Namespace, but here comes the very interesting part!! When you drop a Web Browser control onto a WinForm and you have a peek at the properties, you will see lots of properties that can be set, including "IsWebBrowserContextMentEnabled" and "WebBrowserShortcutsEnabled". Now thats cool!! and is V productive. okay, its seems like a small thing, but not every company has a C++ developer or someone that knows COM/ActiveX to that level and this small thing meets a very common scenario/requirement very nicely, e.g. to do this in C++ takes an absolute minimium of 200+ lines of VC++ code.

For those (re)users of the Web Browser control, have a look! if you have feedback on the control and what it does, go to the MSDN Product Feedback Center

Published Tuesday, October 19, 2004 12:31 PM by no1138

Filed under: - .NET, - Whidbey

Comments

Ismael H. López said:

Hi there,

I´ll be playing around with the webbrowser control of VS2005 beta version in a few days, and i expect a little more functionality than in previus releases, that as you've pointed out weren't really 'developer-friendly' -at least in vb6. But aside from this, i have to say that if you get stuck only to the funtionality that the control exposes directly (i mean, methods & properties) you are loosing all the power that hides behind the DOM.

As an example here's a chunck of code that overwrites the default contextmenu of the webbrowser with another one of your own without
going through VC++ or even implementing IDocHostUIHandler (yes, you can do this in vb6:
http://www.mvps.org/emorcillo/vb6/inet/index.shtml)

CODE
-----
option explicit
Public WithEvents m_htmDoc As HTMLDocument

(...)
Set m_htmDoc = WebBrowser.Document

(...)

Private Sub m_htmDoc_onmousedown()
' Creating a variable to hold elements inside document object,
' and pull off those awful dots that eat resources.
Dim elem As IHTMLElement
Set elem = m_htmDoc.parentWindow.event.srcElement

With elem
' Check if button = 2 (right button) was pressed.
If m_htmDoc.parentWindow.event.Button = 2 Then
Call PopupMenu(frmMDIMain.MnuPUPContext1)
End If
End With
End Sub

salu2.

November 10, 2004 12:12 PM

Paul said:

Hi Ismael,
good comments.

I'm not sure by what you mean by "loosing all the power that hides behind the DOM", as you do have access to the HTMLDocument through the HTMDocument class (see http://msdn2.microsoft.com/library/y9z09bzd.aspx).

Re: "i expect a little more functionality than in previus releases"
I am assume that you are talking about the WebBrowser control here, right? If so, the version of WebBrowser control being used is no different from what is being used by internet explorer, this is a new managed wrapper into a unmanaged control. The unmanaged control is still the same WebBrowser control that makes up all/most of Internet Explorer, its just that the managed wrapper simplies how you interact with it. If you feel that something should be included in the managed wrapper, may I suggest the product feedback center (at http://lab.msdn.microsoft.com/productfeedback/default.aspx).

Also, thanks for the code snippet. I have seen this been used in the past, especially in scripts that are included within a web page and it was its usage in scripts that I was referring to in the post. Going by past experiences in my pre-MS days, I have found few solutions that would leverage this with VB (as the host) in the way you have described. This is why I like what I have seen in the new managed API todate. Its my own personal view, I think there is a certain set of common requirements that reusers of the WebBrowser control will want to have easy control over (such as setting a property) and having this easily availble in .NET is a nice addition

Since, its been about 3-4 years since I was writing custom versions of IE for Task stations for Kiosks, BHO Objects, APP Objects, desktop bands or browser toolbars, I might not recall some of the standard aspects that are common across projects. But have properties to cover some of the features that I covered in the post is certaintly a nice start and as I mentioned before, I would suggest using the MSDN Product feedback center if you have some suggestions for additions/alterations for the managed API/OM

thanks for the comment,

HTH,
Paul

November 18, 2004 12:07 AM

Anonymous comments are disabled

This Blog

Syndication

News

The content of this site are my own personal opinions and are not intended to represent my employer's view. In addition, my thoughts and opinions may change over time, so out of date posts do not necessarily reflect my current thoughts and opinions. These postings are provided "AS IS" with no warranties, and confer no rights.