Re: Question about new AXVisibleCells attribute
Re: Question about new AXVisibleCells attribute
- Subject: Re: Question about new AXVisibleCells attribute
- From: James Dempsey <email@hidden>
- Date: Mon, 8 Mar 2010 10:34:23 -0800
On Mar 6, 2010, at 1:35 PM, Bill Cheeseman wrote:
> I've been fooling around with Apple's Numbers application as a way to test the new Snow Leopard cell-based table attributes.
>
> I'm puzzled by the behavior of AXVisibleCells. With both Accessibility Inspector and a new version of my PreFab UI Browser, the default plain table in Numbers yields an array of 643 UI elements if Numbers is the active application, but an array of only 71 UI elements if Numbers is in the background (but fully visible). The 643 value is correct (13 columns X 45 rows + 13 column headers and 45 row headers). The incorrect 71 UI elements value is composed of only the first row of cells Plus the column and row headers.
>
> Accessibility Inspector and UI Browser are both using the AXUIElementCopyAttributeValues() function.
>
> I assume this is a bug and I plan to report it as such. But I'm curious to know why this is going on, if somebody can tell me. Surely it isn't intentional.
I can't think of a valid reason why the value would change, so this should be reported as an issue. Most likely the accessibility piece of the code is calling into some function or method that unexpectedly has this behavior.
In general AXVisibleCells should behave similarly to AXVisibleRows, AXVisibleChildren, etc. The value shouldn't change just because the application is not frontmost.
-James
--------------------------------------------------
James Dempsey
AppKit Engineering
Apple
email@hidden
_______________________________________________
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