W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 1999

Re: Exposing object model to applications

From: <schwer@us.ibm.com>
Date: Wed, 14 Apr 1999 10:33:15 -0500
To: w3c-wai-ua@w3.org
cc: rrelyea@microsoft.com
Message-ID: <85256753.0055AF50.00@d54mta08.raleigh.ibm.com>

This should be integrated into the techniques section (6.1) that I
submitted earlier this week. It appears to follow the general techniques I
had specified in that the assistive technology can register itself for DOM
access through a system registry mechanism as a DLL with a specified entry
point that can be called with a reference to the DOM.

What is not clear here is whether the IE Object model, IUnknown, will
guarantee full implementation of the DOM interface. My assumption is that
it does. I strongly support Mark Novac's concern that as a minimum an
assistive technology should be guaranteed that the current approved W3C
specification for the DOM be supported.

I had spoke with Chuck Opperman at CSUN and he said that access to IUnknown
was provide but not a publicly supported function. Is this not the case?
Might this change? Is access to IUnknown reentrant?

Rich Schwerdtfeger
Lead Architect, IBM Special Needs Systems
EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",

Rob Relyea <rrelyea@microsoft.com> on 04/14/99 09:42:57 AM

To:   w3c-wai-ua@w3.org
cc:    (bcc: Richard Schwerdtfeger/Austin/IBM)
Subject:  Exposing object model to applications

RR: Write a description of how a browser could expose its internal object
model to other processes including the ability to run a module of the AT to
run in the process.

A browser can expose its internal object to applications throught several
methods.  We are finalizing the method that we will let applications
communicate directly with Internet Explorer's object model.  As soon as the
application to application method is finalized, I will send details.

We already have a way for an AT developer to have a module of their code
inside of IE's process:
Internet Explorer allows software developers to have their code executed
inside of the browser's process.  This can be tremendously helpful when
method calls need to be made to IE, as each call will be performed much
quickly than the out of process case.

A technique to do this is already documented in our Knowledge Base.
Q179230.  This will work in IE4 and later.

Excerpts from:

IEHelper-Attaching to IE4 using a Browser Helper Object

In order to attach to a running instance of Internet Explorer 4.0, you can
use a "Browser Helper Object." A "Browser Helper Object" is a DLL that will
attach itself to every new instance of Internet Explorer 4.0. You can use
this feature to gain access to the object model of a particular running
instance of Internet Explorer. You can also use this feature to get events
from an instance of Internet Explorer 4.0.

This article also points to a sample that demonstrates how to implement a
Browser Helper Object.

The following file is available for download from the Microsoft Software
IEHelper.exe (size: 39419 bytes)

For more information about downloading files from the Microsoft Software
Library, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q119591
   TITLE     : How to Obtain Microsoft Support Files from Online Services

Browser Helper Objects
When an instance of Internet Explorer 4.0 is started, it looks in the
registry for CLSIDs stored under the following key:

       \CurrentVersion\Explorer\Browser Helper Objects

If this key exists and there are CLSIDs listed under it, Internet Explorer
will use CoCreateInstance() to try to create an instance of each object
listed as a subkey under this key. Note that the CLSID of the object you
create must be listed as a subkey and not a named value.

For example, imagine that the following entry exists in the registry,
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper
Objects\{CE7C3CF0-4B15-11D1-ABED-709549C10000}. Internet Explorer will try
to create an instance of the object pointed to by the CLSID {CE7C3CF0-4B15-
11D1-ABED-709549C10000} each time Internet Explorer starts.

These registry keys can be created manually or through the self
portion of your COM application.

There are some requirements when creating a Browser Helper Object

* The application that you create must be an in-proc server (that is, DLL).
* This DLL must implement IObjectWithSite.
* The IObjectWithSite::SetSite() method must be implemented. It is through
this method that your application receives a pointer to Internet Explorer's
IUnknown. (Internet Explorer actually passes a pointer to IWebBrowser2 but
the implementation of SetSite() receives a pointer to IUnknown.) You can
this IUnknown pointer to automate Internet Explorer or to sink events from
Internet Explorer.
* It must be registered as a Browser Helper Object as described above.

WARNING: Internet Explorer will create an instance of each Browser Helper
Object listed in the registry every time a new instance of Internet
is started. This means that if you have Active Desktop installed, the
Browser Helper Objects will be loaded every time you open a new folder as
well as when the browser itself is started.
(c) Microsoft Corporation 1998, All Rights Reserved. Contributions by Scott
Roberts, Microsoft Corporation

Last Reviewed: February 16, 1998
 1999 Microsoft Corporation. All rights reserved. Terms of Use.
Article ID: Q179230

Last Reviewed:
February 16, 1998

Provided by Support Online from Microsoft Product Support Services.
Received on Wednesday, 14 April 1999 11:36:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:21 UTC