Re: AXPosition and AXSize during window drags
Re: AXPosition and AXSize during window drags
- Subject: Re: AXPosition and AXSize during window drags
- From: Michael Ash <email@hidden>
- Date: Sun, 25 Nov 2007 12:00:57 -0500
On Nov 25, 2007, at 7:15 AM, Bill Cheeseman wrote:
But Cocoa UI elements apparently don't update their AXPosition and
AXSize
attributes until a window drag is completed (e.g., TextEditl, Xcode,
Safari). This makes it impossible for my overlay window to track
movement of
a Cocoa window during window drags.
It is impossible to fully track these drags even from *within* a Cocoa
app, as the drag is not synchronized with the main thread (notice how
you can drag the windows of frozen Cocoa apps) and the reported window
frame is not updated in anything like real time. When you let go of
the mouse, it takes about half a second before the framework begins
reporting the correct frame for the window. If the framework can't
even report the correct values to the app that owns the window, the
prospects for correct reporting to other apps seem dim.
This page discusses it further and shows an in-app workaround
(currently down, though):
http://rentzsch.com/cocoa/nswindowFrameLies
However, the lack of synchronization with the main thread is a killer
for your needs, and in any case there's probably no way to apply this
workaround to Accessibility without code injection.
Doing an overlay window in-app is best done by using window groups in
Carbon or child windows in Cocoa. I wonder if there might be a way to
set up such a thing between windows of different apps. I have a
feeling that there is, although it's probably undocumented and evil.
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden