Re: AXToolbarButton issue
Re: AXToolbarButton issue
- Subject: Re: AXToolbarButton issue
- From: Bill Cheeseman <email@hidden>
- Date: Tue, 12 Nov 2002 06:38:50 -0500
on 02-11-11 8:46 PM, Mike Engber at email@hidden wrote:
>
> The AXToolbarButton attribute of the AXApplication element appears to
>
> have a
>
> description of "AXMinimizeButton." I assume this is a bug. But maybe
>
> I'm
>
> reading it wrong. Anybody?
>
>
AXToolbarButton is an attribute of windows, not apps. If you're seeing
>
it as an
>
attribute of an app it's a bug. What app?
>
>
As an attribute of a window, its value should be a UI element with
>
role="AXButton" and
>
subrole="AXToolbarButton". What you describe sounds like some window is
>
returning its
>
minimize button instead of its toolbar button (press it using UI
>
element inspector and
>
see what happens. Either way, it's a bug. What app.
This is very definitely a bug in the accessibility API. Read what follows
carefully. The last two paragraphs prove beyond doubt that the accessibility
API is misbehaving, and it should give you a pretty good clue as to where
the problem lies.
First, I misspoke in my original message. I see the toolbar button as a
string attribute of a WINDOW element (not of an application element), and
this attribute's VALUE (not its description) is reported as a UIElement
having a role of "AXButton" and a subrole of "AXMinimizeButton". That last
part is the bug's doing, since the subrole should be "AXToolbarButton". I
see this bug with respect to every single Cocoa application I've targeted,
including UIElement Inspector itself. (My original message misreported this
as a problem with the description of the application element because I
hadn't really focused on the fact that the title bar buttons are both
attributes and children of a window. I got confused.)
I do most of my testing using my own accessibility browser application, but
for purposes of this email I also used UIElement Inspector. In all cases my
app and Inspector show the same results, so the discrepancies I report here
aren't the result of a bug in my code (unless Inspector shares the same
bug).
Carbon applications (e.g., Internet Explorer, Entourage, BTV Pro Carbon,
Finder) don't report ANY of the buttons in the window's title bar as an
ATTRIBUTE. This seems odd, since Cocoa applications do report them as
attributes. Maybe your Carbon accessibility stuff just hasn't caught up with
the Cocoa stuff yet? Carbon and Cocoa apps both do report these title bar
buttons as CHIILDREN.
The window's CHILD toolbar button UIElement correctly reports its subrole as
AXToolbarButton in every application I've looked at that has a toolbar
button in its title bar. The bug apparently relates only to the reporting of
the toolbar button ATTRIBUTE.
So it looks like, with respect to all Cocoa applications, the accessibility
API erroneously returns the UIELEMENT for the MINIMIZE button as the VALUE
of the window's TOOLBAR button ATTRIBUTE (instead of returning the UIElement
for the toolbar button, as it should), but correctly returns the toolbar
button UIElement as one of the CHILDREN of the window UIElement.
Using UIElement Inspector's goto pop-up menu, I wentto the TOOLBAR button
element listed among the window's ATTRIBUTES and -- guess what -- UIElement
Inspector opened the MINIMIZE button! I can tell its the minimize button,
not only because it's subrole is reported as AXMinimizeButton, but also
because it gives the same AXPosition as the REAL minimize button. So there's
your bug.
Here's another clue. I do most of my testing on Text Edit (a Cocoa app). I
see an AXToolbarButton ATTRIBUTE of a TextEdit window (along with the close,
minimize and zoom button attributes), and the AXValue attribute of the
toolbar button reportedly has a subrole of "AXMinimizeButton". But I don't
see a toolbar button among the window's children, because THERE IS NO
TOOLBAR BUTTON IN A TEXTEDIT WINDOW. So this result is entirely spurious.
Ah, I see that the toolbar button attribute is reported in EVERY Cocoa
application's window, even though the windows DO NOT HAVE A TOOLBAR BUTTON.
Even UIElement Inspector itself exhibits this misbehavior, when you place
the mouse over the Inspector's own title bar. So somehow the bug lies in
thinking that every Cocoa window has a toolbar button, or in thinking that
the existing minimize button is also a toolbar button.
Hope this is helpful. I'll report it to RadarWeb.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
accessibility-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/accessibility-dev
Do not post admin requests to the list. They will be ignored.