INFO: Not all OLEAcc.dll Proxies Live in Client's Address Space

ID: Q195422

The information in this article applies to:

Microsoft Win32 Software Development Kit (SDK)

SUMMARY

Proxies created as a result of navigating from a native IAccessible object live in its address space. This can cause a performance overhead in the applications or the proxy itself can become unavailable when the Server application exits.

MORE INFORMATION

Usually, OLEAcc.dll proxies for USER/Common controls and registered handlers live in the address space of the client.

However, a client might need to communicate with an OLEAcc.dll proxy living in a different address space. These proxies could be proxying for objects in a third process space. For example, the proxies for Notepad controls live in the Internet Explorer address space.

Native IAccessible objects typically handle navigation requests by calling CreateStdAccessibleObject() and returning the resulting object. Returning the resulting object merely causes OLE to create stubs in both caller and callee process spaces to facilitate cross-process boundary communication with that object. It is important to note that CreateStdAccessibleObject() creates a proxy in the address space of the immediate caller, the native IAccessible in this case, and it remains there. This is also true in the case when a navigation method is called on an "in-process" proxy, that is, one that is in the same address space as the client.

Sample Scenario

A client application gets a focus event from a native IAccessible server like the Server.cpp sample server. It then uses AccessibleObjectFromEvent() to get a corresponding IAccessible object. It calls the get_accParent method of the IAccessible interface on that object, which in turn calls CreateStdAccessibleObject() internally. This results in a proxy being created in the server's address space. The client then calls the get_accParent method again on this proxy. This proxy then calls CreateStdAccessibleObject internally, creating another proxy in the server's address space. The client then calls the accNavigate method on this new proxy which results in another proxy being created in the original server's address space. As the client navigates to a totally different application using NAVDIR_NEXT, NAVDIR_FIRSTCHILD and so forth, more proxies are created in the original server's address space.

There are two problems with this scenario:

First, there is the performance overhead due to unnecessary OLE cross- process calls. A proxy is created by the client using OLE, even if both are in the same address space.

Second, when the server application exits, the proxies in its address space, even if proxying for different applications, become unavailable.

Please note that this affects client applications that use navigation extensively. The clients that obtain IAccessible objects by responding to events or by using AccessibleWindowFromPoint() will not encounter this problem.

REFERENCES

Microsoft Active Accessibility

Additional query words:

Keywords : kbAAcc kbNavigation
Version : WINDOWS:
Platform : WINDOWS
Issue type : kbinfo