- 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.", Frost 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 run 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 many method calls need to be made to IE, as each call will be performed much more quickly than the out of process case. A technique to do this is already documented in our Knowledge Base. Article Q179230. This will work in IE4 and later. Excerpts from: http://support.microsoft.com/support/kb/articles/Q179/2/30.asp IEHelper-Attaching to IE4 using a Browser Helper Object SUMMARY 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. MORE INFORMATION The following file is available for download from the Microsoft Software Library: 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: HKLM\SOFTWARE\Microsoft\Windows \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 registration 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 use 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 Explorer 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