Re: Finder Moves its AXFinderItem around?
Re: Finder Moves its AXFinderItem around?
- Subject: Re: Finder Moves its AXFinderItem around?
- From: Matt Budd (Madentec) <email@hidden>
- Date: Fri, 18 Feb 2005 16:17:03 -0700
Hey Bill. Thanks for the response. I will respond inline. Note that I
will use UIEI as shorthand for UIElementInspector.
- Matt
On Feb 18, 2005, at 4:32 AM, Bill Cheeseman wrote:
I was messing with UIElementInspector and the Finder (10.3.8), and
noticed some slightly strange behavior.
- If the finder window is in List mode, then none of the files show up
in UIElementInspector (i.e. Finder doesn't expose a AXFinderItem).
I believe that an AXFinderItem is not a reference to a file, but a
reference
to the iconic representation of a file that appears in a Finder
window's GUI
in icon view or column view. After all, the accessibility API is all
about
the GUI, not about the underlying file system.
This is fine, but that still doesn't justify the strange behavior I'm
seeing (see below)...
In a Finder window in list view, the representation of a file is as a
text
field in a row in an outline view (and the text field contains both an
image
UI element [the icon] and a text UI element), not as a Finder item.
You and
I might have implemented the Finder's list view differently, but this
is how
Apple implemented it. (Actually, the surprise from my point of view is
that
column view doesn't use text fields, as list view does, because the
columns
in column view are more directly analogous to lists [table views or
outline
views] than to collections of freeform icon items.)
I first put a Finder window into List Mode (by hitting command-2 or
using the "View -> As List" menu), then I launch UIEI and hover the
mouse over the files. What I see is that UIEI does not change as it the
mouse hovers over different files. However, using your UI Browser (a
cool app by the way), I see what you mean about the AXOutline and the
AXRows. It's weird though that none of the AXRows have AXOpenAction
actions like they do in the other modes... So I guess this is a flaw of
UIEI in that it doesn't look for the right things that your app does...
- If the finder window is in Icon mode, then they do show up as
AXFinderItems, but it seems that Finder moves the item that I Lock
onto. To see this, open up a finder window in icon mode, Lock onto one
of the icons and choose highlight in the interaction window, and then
select one of the other icons in the finder window. Then hit refresh
on
the interaction window and you will see that the AXFinderItem you
locked onto is now a different one (and it's even different than the
one that you selected in Finder)...it seems to be a cyclical pattern.
I don't see the icons move when I try this, but I think I may have
misunderstood what you mean by "move." Perhaps you mean that
UIElementInspector highlights a different icon than you expect it to
highlight?
I do see that UIElementInspector highlights the "wrong" icon if you
select a
different icon in the Finder AFTER locking down UIElementInspector on
the
first icon. I don't have time to explore what's happening here, but it
would
seem that UIElementInspector is highlighting whatever icon is currently
selected in the Finder even though UIElementInspector itself is locked
on
another icon. If this is right, then it's just a logic bug in how
UIElementInspector's highlight button is implemented -- it's using a
non-lockdown mode for the highlight button when the rest of
UIElementInspector is locked. I can imagine that this logic error might
propagate somehow as you continue to work with a locked
UIElementInspector
in the Finder window.
Yes, you are right about what I meant. I mean that UIEI highlights a
different icon than I expect it to highlight. When I lock onto one icon
using UIEI, and then use my mouse and select a different icon AFTER
locking UIEI down, then hit Refresh on UIEI, a third icon is
highlighted instead of the first one I locked onto and instead of the
second one I selected with my mouse. Now this behavior is not
completely consistent, but if you lock onto one and select enough other
ones, you will notice this problem (as you said you had).
What I am saying is that I don't believe this is a bug in UIEI's
highlighting. In some throwaway code I did before the post, I would
have a AXUIElementRef on the one icon, and do an NSLog() of its
position and size. I would then use the mouse to select a different
icon in that window and redid the NSLog() and the rect
changed....basically Finder is giving me a AXUIElementRef and then
changing which one that points to based on which one is selected with
the mouse (and it's not even the one that you selected; it's a weird
cyclical pattern). Perhaps both UIEI and I are performing the same
wrong code, but we both experience this weird shifting of a UIElement
reference.
And I just downloaded your demo of UI Browser (UIB) and I can also
recreate the issue with it. Simply navigate to a Finder window that's
in Icon Mode, and use UIB to drill through to one of the items and open
the Actions Drawer for that Finder Item. Then use your mouse and select
one of the other icons in that window. Then without re-drilling in UIB,
perform the AXOpenAction in UIB....you will see that it actually opens
a different one! The reference that you were given by Finder has been
changed by Finder to point to a different Finder Item! Am I going crazy
or is this just happening on my machine?
- If the finder window is in Column mode, then the icons show up as
AXFinder Items, and this weird "moving" behavior doesn't happen and
everything works as you'd expect.
Since column view doesn't allow spatial movement of icons, I'm not
sure why
you would expect to see "moving" behavior in column view.
If you mean only that you don't see the wrong icon being selected in
column
view, I don't either.
Again, I meant the highlight, so you are right and we see the say thing
in column mode (command-3)...things are exposed correctly and Finder
doesn't "move" references around..
- When you switch between modes, the AXFinderItem becomes undefined.
Wouldn't we expect that it would be constant regardless of view mode?
From playing with Finder views in PreFab UI Browser, I see that the
accessibility API considers that all of the UI elements in one view are
"destroyed" when you switch window views. This is entirely consistent
with
the theory underlying the accessibility API -- It is focused on the
GUI as a
user with disabilities would see it, so when a UI element is no longer
visible, it no longer exists. There are many "close cases" when
deciding how
to implement this theory, but that's how it appears to have been
implemented
for Finder window views.
Nevertheless, brief experimentation with UI Browser suggests that the
AXFinderItems that appear in icon view and in column view can be
referenced
by the same title attribute, as I would expect. They can also be
referenced
by the same index number when scripting Finder window views using GUI
Scripting (which is based on the accessibility API), so you can write
scripts that will work in either of those views (as long as you
account for
the differing containment hierarchies).
I can live with this as I can see your point about how it makes sense
from a GUI-centric focus of the API.
So overall it really comes down to how Finder is acting in Icon mode.
It is just doing some strange things and when it gives you a
AXUIElementRef, I guess you cannot trust that it actually points to the
one that you first requested. Perhaps every time you want to perform
actions on AXFinderItems in Icon Mode, you will have to requery Finder
for the item that matches the title and description.... is there any
other way?
Thanks for all your help Bill, it really helps to figure this out with
someone who obviously has done a ton with the AX API...
- Matt
_______________________________________________
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