用浏览器控件做界面，网页界面中定义自己的程序事件

痛定思痛。 2022-08-24 01:54 216阅读 0赞

1　引言  
在用Delphi、Visual Basic等可视化快速开发工具编写Windows应用程序时，常会遇到这样几个问题：  
1) 希望程序界面美观。在Delphi中，开发人员通常使用各种控件来实现界面的风格化，但缺点是造成应用程序体积较大，且在升级时常会被控件版本与Delphi版本不兼容带来的问题所困扰。  
2) 希望应用程序在功能不变的情况下具有不同的界面风格。这常常通过换"皮肤"的技术来实现，但一般实现"换肤"功能的控件体积都较大，且界面反应速度比较慢，而且 "皮肤"的制作比较麻烦。  
3) 程序界面的维护困难。为了使界面与代码实现相分离而获得"换肤"等灵活性，通常要用到一些设计模式的技术，这对于不熟悉设计模式的开发人员来说比较困难。

微软公司预计将于2006年发布下一代操作系统（开发代号为Longhorn）中，应用程序的结构及部署将有重大变革，其中一项就是应用程序的界面完全以XML的一个扩展集XAML语言来描述，以便达到界面的高度可定制性。这无疑能够方便地解决上述几个问题。问题是在目前来说有没有类似的方法呢？答案就是使用浏览器控件。  
微软公司的网页浏览器Internet Explorer的核心被设计为可以嵌入到应用程序中重用的ActiveX组件，它有极强的可编程能力和与容器交互的能力，使得开发人员能够快速地开发出功能强劲的应用程序。从下面的Internet Explorer的架构图可以看到，我们平常运行的iexplorer.exe其实只是一个外壳程序，真正的浏览网页、记录历史等工作是由嵌入其窗口的封装在shdocvw.dll中的WebBrowser Control来完成的。

Shdocvw.dll的功能则是调用mshtml.dll来解析网页，以及在它的窗口中嵌入其它活动文档组件（如Microsoft Office、Adobe Acrobat等应用程序的文档都可以嵌入到浏览器窗口中查看）。而mshtml.dll一方面处理HTML解析以及作为脚本引擎、java虚拟机、ActiveX控件、插件的宿主，另一方面，它实现了活动文档服务器接口，允许应用程序以标准的COM接口来把它嵌入到程序中并通过它暴露的接口来访问其中的网页及网页元素。  
通过shdocvw.dll提供的丰富接口，网页中的元素可以访问外壳应用程序提供的属性和方法（如window.external.AddFavorite(location.href, document.title)则是调用IE的AddFavorite方法把当前页添加到收藏夹），而通过mshtml.dll提供的接口，外壳应用程序则反过来可以访问网页中元素的属性、方法、行为、事件等等。解决文章开头提出的几个问题的方法就是基于shdocvw.dll和mshtml.dll实现的。一些著名软件如：Microsoft Money、Microsoft Visual Studio .NET、Macromedia Dreamweaver MX 2004等都运用了这种技术。

2　原理  
1) 程序的界面完全由制作网页来完成。网页在文字、图像、声音等方面具有强大的表现能力，运用所见即所得的网页制作工具可以轻松制作出图文并茂的网页。以网页作为程序的界面，其效果胜过任何界面控件。  
2) "换肤"功能容易实现。只需制作不同风格的网页，即可轻松实现样式各异的程序界面。  
3) 程序的功能在应用程序内部编写代码来实现，并通过一个自动化接口提供给网页中的元素调用。这就实现了程序界面和代码的分离，网页布局及风格的改变不会影响到程序的实现。

3　从网页调用外壳程序的属性和方法  
3.1　GetExternal接口方法  
WebBrowser Control提供的接口使得外壳应用程序可以用自己的对象、方法和属性等来扩展IE的对象模型（DOM），以达到个性化定制的目的。在网页中访问外壳应用程序的扩展则通过文档的"external"对象来实现，如外壳程序提供了名为AddFavorite的方法，网页中就通过window.external.AddFavorite()来调用。实现这一功能的核心是IDocHostUIHandler接口的GetExternal方法：  
HRESULT GetExternal(IDispatch \*\*ppDispatch);  
在自定义的WebBrowser Control中实现IDocHostUIHandler接口，当网页元素通过"external"对象访问外壳扩展的属性和方法时，GetExternal方法就会被调用，在此方法的中将实现外壳程序属性和方法的自动化接口传递给ppDispatch即可。自定义的WebBrowser Control示例代码如下，在其中将GetExternal包装为OnGetExternal事件供外部程序调用。IDocHostUIHandler接口有15个方法，此处我们只关心GetExternal方法，故略去其余14个（省略号处为略去的代码）。  
unit ZoCWebBrowser;

interface

uses  
Variants,IEConst, Windows, SysUtils, Classes, SHDocVw, ActiveX, shlObj, MSHTML, comobj;

type  
……  
TGetExternalEvent = function(out ppDispatch: IDispatch): HRESULT of object; //定义OnGetExternal事件类型  
TZoCWebBrowser = class(TWebBrowser, IDocHostUIHandler)  
private  
……  
FOnGetExternal: TGetExternalEvent;  
protected  
……  
function GetExternal(out ppDispatch: IDispatch): HRESULT; stdcall;  
published  
……  
property OnGetExternal: TGetExternalEvent read FOnGetExternal write FOnGetExternal;  
end;  
……  
implementation  
……  
function TZoCWebBrowser.GetExternal(out ppDispatch: IDispatch): HRESULT;  
begin  
if Assigned(FOnGetExternal) then  
Result := FOnGetExternal(ppDispatch)  
else  
Result := S\_FALSE;  
end;

initialization  
OleInitialize(nil);  
finalization  
try  
OleUninitialize;  
except  
end;  
end.

3.2　实现外壳程序扩展自动化接口  
在Delphi的"New Items"对话框中，切换到"ActiveX"页，选择"Automation Object"，新建一个自动化对象，并在"CoClass Name"一栏中填入接口名"MyExternal"，"Instancing"选择为"Internal"，表示该对象只能在程序内部被创建，外部程序不能直接创建。点击"OK"按钮后在Type Library编辑对话框中为IMyExternal接口添加两个方法ShowAboutBox和SwitchUI，此时代码大致如下所示：

unit MyExternalImpl;

\{$WARN SYMBOL\_PLATFORM OFF\}

interface

uses  
ComObj, ActiveX, Project1\_TLB, StdVcl;

type  
TMyExternal = class(TAutoObject, IMyExternal)  
protected  
procedure ShowAboutBox; safecall;  
procedure SwitchUI; safecall;  
end;

implementation

uses ComServ;  
procedure TMyExternal.ShowAboutBox;  
begin  
MessageBox(MainForm.Handle, ‘GetExternal Demo’, ‘ZoCWebBrowser’, MB\_OK or MB\_ICONASTERISK);  
end;

procedure TMyExternal.SwitchUI;  
begin  
ShowSwitchUIForm; //显示切换程序界面对话框  
end;

initialization  
TAutoObjectFactory.Create(ComServer, TMyExternal,  
Class\_MyExternal, ciInternal, tmApartment);  
end.

3.3　从网页中调用外壳程序接口  
在程序主窗口中放置一个自定义的WebBrowser Control，命名为ZoCWebBrowser，编写它的OnGetExternal事件（由网页中的window.external调用触发），代码如下：

function TMainForm.ZoCWebBrowserGetExternal(  
out ppDispatch: IDispatch): HRESULT;  
var  
MyExternal: TMyExternal;  
begin  
MyExternal:= TMyExternal.Create; //创建实现自动化接口的对象  
ppDispatch :=MyExternal; //将对象接口传递给WebBrowser Control  
//这样当"external"对象被调用时，真正被调用的是我们实现的TMyExternal对象  
Result :=S\_OK;  
end;

假设我们制作了两个风格迥异的的网页Style1.html和Style2.html作为程序界面，这两个网页中都有两个按钮（也可以是其它网页元素），其HTML代码示例如下：  
关于  
切换界面  
在程序开始运行时让WebBrowser Control布满整个Form，且显示Style1.html页面，则当点击"关于"按钮时程序将显示一个关于信息对话框，而点击"切换界面"按钮时将显示切换界面的对话框，在其中选择Style2.html并让WebBrowser Control显示它即可获得风格完全不同的界面，但在功能上与Style1.html完全一样。

4　总结  
从上面的例子可以看到，我们以及其简单的方式实现了程序界面与实现的分离，这有利于程序的维护和扩展。传统方式下，界面设计和编码通常都由程序员来完成，一来造成程序员负担较重，二来难以保证界面质量。实用上述方法，程序界面可以由专业美工人员来设计，他可以在完全不知道程序如何实现的情况下设计出完整的界面，而程序员只需专注于代码的编写，并将必要的方法和属性通过一个自动化接口暴露出来。合并的时候，在网页中合适的位置放入所需的按钮或其它网页元素，并赋予简单的脚本调用即可。

（以上代码均在WindowsXP+Delphi 7环境下调试通过）

5　参考文献  
《MSDN Library - July 2003》

作者Blog：[http://blog.csdn.net/CathyEagle/][http_blog.csdn.net_CathyEagle]  
原文地址：[http://blog.csdn.net/cathyeagle/archive/2004/10/27/154224.aspx][http_blog.csdn.net_cathyeagle_archive_2004_10_27_154224.aspx]

C\# 版

使web 页面回调本地应用程序。C\#  
在开放windows应用时，经常会用到浏览器组件，使你的应用程序能够显示web页面。 但是web页面和你的应用程序是独立的两部分，他们无法进行交互。 能否有办法让你的web（html）页面，回调你应用程序中的函数或方法呢？

在开放windows应用时，经常会用到浏览器组件，使你的应用程序能够显示web页面。 但是web页面和你的应用程序是独立的两部分，他们无法进行交互。 能否有办法让你的web（html）页面，回调你应用程序中的函数或方法呢？ 使web程序和你的本地应用程序混为一体，下面这篇文章提供了通过microsoft api 使web 页面回调应用程序的途径。 相关例子到这里下载 ，本例为C＃编写。

Hosting a webpage inside a Windows Form

Introduction  
This article discusses my journey toward having a web page run inside of a WinForm client and fire events back to it. The sample app which is included provides the implementation of this article. While the sample application could have been done in an easier fashion (all ASP.NET for example) the intent is to provide a working model that can implement more difficult designs.

The Application  
The application consists of a WinForm application which is broken into two sections:

The right side is the web app  
The left side is the winForm pieces that gets populated based on what was clicked in the web  
The application implements the IDocHostUIHandler interface which will allow MSHTML to do callbacks into my code. It then displays the webpage inside the IE container. When a button is clicked, a javascript component is called with a text description of what was clicked on. The javascript passes this data to the external method which will populate the form with data. If data is not found, the purchase button is disabled.

To make the application work on your machine, alter the application config file (SampleEventProgram.exe.config) in the BINRelease directory and change the path to where the sampleweb application is located on your machine.

The Research  
Not being a raw, C++ COM developer - or even knowing much about the internals of the IE engine - I began my deployment by researching on the Internet. The first day I searched the web for anything on putting IE inside a form. I bring this up because it led me to a webpage which appeared to be a BLOG. I read it out of interest to see why the heck it showed up in my search. In it, the author said:

"In my growing years of development, I have had several unanswered questions arise. \[...\] Why is it so hard to implement a web browser inside a windows form and take control of it?"

I probably should have taken this as a warning, but I plunged forward in my quest. After all, MS had years to improve this proces….right? Over here at CodeProject, I came upon a discussion thread that died with no conclusive help, as well as articles by Wiley Techology Publishing and Nikhil Dabas. The first article was well written, but the most important part of the piece (implementing IDocHostUIHandler and ICustomDoc) were taken offline and done in Delphi! Nikhil’s article, however, had a fine discussion on implementing the interface as well as a deployed DLL for the interfaces in his sample application!

However, his deployment for hooking events required that you know the specific controls on the webform and then sink their click events. It also did not allow the web app to send any information back to the winform client. This is great for having the click events dive directly into code. But I needed the HTML object to tell me some information about what was clicked. So while I finally got IDocHostUIHandler implemented, I still did not get my last piece done and working. I was stuck for weeks in a continuous result of ‘object null or not an object’.

I had a few hints such as looking into GetExternal and I could SWEAR that a post suggested using window.getExternal in my javascript. Obviously that didn’t get me very far since I have since learned that is not a valid javascript call. I also got some suggestions on implementing IDispatch. But nothing really seemed to take the final step of scripting my program.

A lengthy two-day discussion with CP member .S.Rod. finally led to a better understanding and a great assistance in getting everything tied together and working. The most interesting thing with all of this research is that I talked to maybe four different people and got four different implementation approaches. I am sure that in each of those, the person in the discussion had an approach that eventually worked for them. Unfortunately, it was not until my final discussion that I had one that got me past the null object problem.

The only other drawback to all of this research was that I found I was occasionally killing myself by taking input from several people, combining it all together, and having conflicts with what was already done. To make matters worse, I was given a new computer in the middle of all of this and spent two days getting everything back to normal! It was just when I was ready to walk away from this project for awhile that .S.Rod. was kind enough to pull everything together for me. Here are the final results, and a sample application to help guide others in their quest to control IE.

The Code  
For this application I am going to have a webpage present buttons and graphics for a product catalog. Clicking on a button in the webpage will populate the form with descriptions and activate the purchase button. Clicking on the purchase button in the winform will send Lefty Larduchi to your front door for some money. My first step was just to build the webpage (just plain HTML and javascript) and get it to a point of displaying stuff.

Creating the form is not a problem. Just start a new C\# Windows Form project, customize the toolbar and add Internet Explorer from the COM side of the fence. The form consists of a panel docked to the left, a slider, IE docked to the right, and two textboxes and a button that are inside the panel.

Now one of the first steps in taking control of IE is to implement IDocHostUIHandler. Nikhil wrote a fine article on doing this, so I won’t duplicate his efforts. You can cover that first step here.

Make sure you keep track of the MSHtmHstInterop.dll piece of his sample application. I used the sample app to copy and paste the base IDocHostUIHandler implementations into my form.

So after implementing IDocHostUIHandler, what else needs to be done? Well, in Nikhil’s article his example would require that you know the controls that will be clicked and that someone click on that control. This is the code that accomplishes that:

private void WebBrowser\_DocumentComplete(object sender, AxSHDocVw.DWebBrowserEvents2\_DocumentCompleteEvent e)\{ IHTMLDocument2 doc = (IHTMLDocument2)this.WebBrowser.Document; HTMLButtonElement button = (HTMLButtonElement) doc.all.item("theButton", null); ((HTMLButtonElementEvents2\_Event)button).onclick += new HTMLButtonElementEvents2\_onclickEventHandler(this.Button\_onclick);\}  
I had to face an application requirement where we were showing major sections, with each section being just DHTML, each section had to provide me information about itself and then have the WinForm act upon that information. I found it interesting to find in all the numerous articles I read on this subject that Outlook deploys this WinForm/IE merge - just not in .NET!

In this example, we are using the javascript object window.external to interact with the form. So when a user clicks on a section it will fire a method in the script area. That method, via window.external, issues a call through MSHTML to the IDocHostUIHandler.GetExternal method, then uses the IDispatch methods to get the address of the method and call it. This next section is quoted from a discussion with .S.Rod. I couldn’t describe it better:

anyone willing to implement custom menus or external method calls should register a custom site handler. That’s what is done with the ICustomDoc.SetUIHandler(object) method call.  
the passed object reference has to implement the IDocHostUIHandler interface, an IUnknown based interface. Among the methods are one which is used as an entry point for all window.external.mymethod() calls, that’s IDocHostUIHandler.GetExternal(out object ppDispatch).  
the GetExternal method should return a reference to an object which implements a dispatch interface. In case you don’t know, a dispatch interface is a standard automation interface providing the ability to have methods called by their names, thanks to two helper methods : GetIdOfName() and Invoke().  
the good news is that the .NET Framework provides the attribute,

\[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)\]

which implements all the underlying plumbing. What’s left to do is to declare and implement the actual methods.  
In the end, we have a sample html file, which reacts on clicks by calling javascript’s window.external.MyMethod(). In order for this to work, the afore mentioned object must be declared and implement the MyMethod() method. In the sample application, that method name is

public void PopulateWindow(string selectedPageItem).  
It should be important to note at this point that any method which will interact at the COM level should be defined to always return void. If there is need to return data, that is done via the parameters with the return parameters marked as out. If there is a need to return an error, for example, that is done by setting an HRESULT via System.Runtime.InteropServices. Setting the HRESULT is done in C\# by doing a

throw new ComException("", returnValue)  
returnValue is an int value defined somewhere in your class, and is set to the value you want to raise.

In the sample application, the first step to exposing an object via IDispatch is to create the custom interface:

\[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)\]interface void ICallUIHandler\{ void PopulateWindow(string selectedPageItem)\}  
Then we implement the interface in a class definition:

public class PopulateClass:IPopulateWindow\{ SampleEventProgram.Form1 myOwner; ///

/// Requires a handle to the owning form ///  public PopulateClass(SampleEventProgram.Form1 ownerForm) \{ myOwner = ownerForm; \} ///  /// Looks up the string passed and populates the form ///  public void PopulateWindow(string itemSelected) \{ // insert logic here \}\}  
So what we have done here is create an interface that exposes IDispatch, we implemented that interface in the PopulateClass class definition, and we take in the constructor logic a pointer to our form. This give access to the specific fields we choose. I’m going to need the class to be able to change the two textboxes as well as enable the button. So I have to go into the form code and change those three item definitions from private to public. So in these definitions, I have made the following connections:

My interface is bound to IDispatch  
My class is bound to my interface  
My class is bound to my form, acting like a bridge between the MSHTML world and C\# .NET world  
Finally I have to implement the last piece of code that will connect my webform to my class I defined above. In the implementation for IDocHostUIHandler.GetExternal I need to set the object passed to an instance of my class. In implementing IDocHostUIHandler, you should have taken the implementation from Nikhil’s sample app and cut/paste it into your program. Alter the necessary implementation as follows:

void IDocHostUIHandler.GetExternal(out object ppDispatch)\{ ppDispatch = new PopulateClass(this);\}  
This now ties your class to the window.external portion of mshtml, it ties the form to the new class definition, and it readies everything for processing. The class implementation basically acts as a go-between between the two worlds of System.Windows.Forms.Form and Microsoft.MSHTML and your web form. The final step - before I write my code in the PopulateWindow method - is to pick which fields I want my class to access and change their definition from private to public, or to follow better coding standards - add public accessors to those fields. In this sample, I exposed the various elements that were to be changed with public accessors.

Conclusion  
Now that I have a working application as well as a working sample application, I have to wonder why it took so long to pull all of this information together. But now, here it is. In the sample application:

The WinForm loads and the constructor is called  
InitializeComponents occurs. This loads the WebBrowser control.  
The WebBrowser is loaded with about:blank which will initialize the document object portion of the browser.  
With the document initialized I can now implement IDocHostUIHandler via the ICustomDoc interface.  
Finally the html page is loaded.  
When an HTML button is clicked, it calls the method CallHostUI passing it the name of the item clicked.

The CallHostUI script calls window.external.PopulateWindow() passing the text each button sends.  
window.external calls through MSHTML into IDocHostUIHandler.GetExternal and gets set to an instance of the object.  
The logic to set the instance also passes reference to the form. Next it uses IDispatch to discover the PopulateClass method and where it is located.  
The method is called, the reference to the form gives the class access for modifying the fields and enabling the button.  
With all of this working I should add a note of warning. I have found that the Visual Designer code does not expect you to have an interface and class definition in front of your form definition. The result is if you add a control or modify a control it visually appears to take, but no change in your code has actually occured and the change disappears once you close and reopen the project. More frustrating is when you add an event handler: you get the binding to the delegate, but no actual base method implementation. Fortunately, all you need to do to work around this is to move your interface and class down to the bottom of your source code.

This can provide a very rich form of client presentation as well as rich WinForm elements for processing data. In my particular example, I’m exposing webpages developed for our internal web UI presentation engine. When each section inside of a web page is moused over, the section is highlighted with a bright yellow border. Clicking on the section passes that information to my WinForm which expresses that section in a properties page display. The various built-in editors in the framework as well as custom editors we write will hook into that properties page to allow for simple modification of data. For example, changing color in a cell element pops up the color picker editor and changing a font pops up the font picker editor.

About theRealCondor

Developer for almost 30 years.  
Developed a new OS, wrote a multi-threaded, queued TP Monitor, AI, .NET application processing engine.

Interested in game development concepts, evolutionary development with genetic algorithmic patterns, 3D modeling, and raising Koi in my pond and rare African Cichlids in my aquarium.

[http_blog.csdn.net_CathyEagle]: http://blog.csdn.net/CathyEagle/
[http_blog.csdn.net_cathyeagle_archive_2004_10_27_154224.aspx]: http://blog.csdn.net/cathyeagle/archive/2004/10/27/154224.aspx