Archive of UserLand's first discussion group, started October 5, 1998.

Re: Can MSIE talk COM?

Author:Michael Winser
Posted:12/12/1998; 8:11:36 PM
Topic:Can MSIE talk COM?
Msg #:1145 (In response to 1127)
Prev/Next:1144 / 1147

This is a very interesting question. For those who don't know, I am one of the many developers who work on IE.

If the traditionnal model of web pages (where links cause navigation to new locations) is desired then I don't think HTTP is terribly inefficient and newer versions of the protocol go a long way to addressing the more glaring problems. None of these problems (high latency slows down multiple connects and requests) affects a local connect at all.

If the web model is not important and using the browser as an application user interface is the goal then there are definitely ways that content can be injected into the browser (actually the current document) via COM. The DOM provides extensive support for creating and manipulating elements both in and out of the primary document. You can also paste HTML text directly into the document.

The best place to start is to look at the IHTMLDocument interface. This interface is not exposed from the appliation window or even the WebBrowserOC (the ActiveX control that wraps the browser) but you could write a small control or binary behavior that would initiate the connection to the server.

Of course this interface is what we call dual so once the connection is established, all document manipulation can be done using a scripting language. Depending on Frontier's support for IDispatch this may be transparent in userscript or may require some wrapping.

It should be obvious from the above that the IHTMLDocument interface is actually the window.document object from the browser scripting object model.

While you're exploring these ideas, I strongly recommend you take a look at the HTA part of IE 5. This is a special host for the core browser that is specifically designed for building applications out of HTML. It doesn't impose nearly as many security constraints on the client script (which is effectively how you would be operating).

Someone else suggested writing a special com: pluggable protocol. I really doubt this will yield any performance benefits and won't change the model at all.

Now it comes down to what you want to do. It isn't at all clear to me calling APIs to generate an HTML document is significantly easier than spewing out HTML tags.

There is little doubt that pasting HTML into an existing document is certainly more efficient than navigating to a new document (regardless of the protocol). The text will be parsed but we won't have to tear down the old document and rebuild a new one. However, if each operation effectively replaces all the current content, all you have saved is the time spent sucking bits through a TCP/IP socket. Hardly worth the effort.

I hope this helps,

Michael

There are responses to this message:

This page was archived on 6/13/2001; 4:46:30 PM.

© Copyright 1998-2001 UserLand Software, Inc.