Even if IA2 is changed to support this flag then it's not reliable way
of detecting AT since AT might not support this flag or AT might not
support IA2 at all.
Thanks.
Alex.
On Tue, May 25, 2010 at 10:46 PM, Andres Gonzalez andgo...@adobe.com wrote:
WM_GETOBJECT is NOT a reliable way of
Pete and all:
Andres, So far I have been told by two AT developers that using WM_GETOBJECT
is how to do it. I guess there is no downside to them though :-)
We use WM_GETOBJECT, SPI_GETSCREENREADER flag, and additional low level system
info. It is mostly an app development problem, not an AT
Any application that would test other native applications would use this.
For example: Rational Functional Tester.
Rich Schwerdtfeger
CTO Accessibility Software Group
Pete Brunet
Yes, but my point is that these functions are not only used by ATs. UI
Automation was designed for full automated testing of Windows.
Accessibility was simply added to it after the fact.
I do know that RFT uses MSAA and UIA for testing and not for accessibility
purposes.
Rich Schwerdtfeger
CTO
In the case of apps using MSAA or UIA for testing purposes the
WM_GETOBJECTs would be expected by the app and thus not a false
positive.
I'd be interested to know why and how Watcom Tablet drivers and Dragon
Dictate are causing WM_GETOBJECTs.
Pete
===
Richard Schwerdtfeger wrote:
Yes,
On 25/05/2010 11:46 PM, Andres Gonzalez wrote:
WM_GETOBJECT is NOT a reliable way of detecting AT either, since it may
be triggered by apps and even device drivers that don't have anything to
do with AT
If an app sends WM_GETOBJECT, it clearly wants accessible or native
objects, otherwise it
On 26/05/2010 12:47 AM, Andres Gonzalez wrote:
The downside is to app users not using AT but experiencing a
performance degradation, however minor.
Not so minor in some cases.
The question is why it isn't minor. That suggests that the accessibility
code on the app side is doing too much that
