Accessibility Inspector gives different results from UI Browser

Scripting Forums AppleScript | Mac OS X
#1

Good afternoon - calling all UI scripters, calling all UI scripters!

Has anyone else noticed that Accessibility Inspector gives a different result from UI Browser in some instances?

For example, in the very misbehaving UI app I am scripting, the window indexes often change, windows are not named, mostly all (except main window) are “AXunknown”, etc. In UI Browser I constantly have to update the screen to refer to the current window index when I make changes in the app itself (like, collapsing a palette). It doesn’t seem to “remember” the UI Element, which is fine - they may have done it that way to ensure compatibility with GUI scripting, I don’t know. In any event, locating the same exact element in Apple’s Accessibility Inspector “locks on” to that UI element, and even if I collapse window palettes, move them around, change to a different view within that window entirely, etc etc, it still can perform actions on that UI element, even if it’s totally hidden. This is extremely, extremely nice and would solve all my problems in a heartbeat. Alas, I cannot figure out how to “latch” onto a UI Element in applescript, so my code currently goes thru and searches for the UI element each and every time. Also the code does not work if the window palette is collapsed. In other words if the UI Element is hidden, the script won’t perform the requested action (for example, click a button to increment a value).

I wonder if there’s a method like Accessibility Inspector uses to latch onto UI Elements that we can use in our applescripts, or is this just something we’ll have to deal with until better UI support comes along?

I’m quite new to this, and I could be vastly mistaken, but it seems like the UI scripting community is still in its infancy. It would be nice if there was a UI scripting specific board, or website, or something. Thoughts?

#2

UI scripting is at least 50% trial end error, because there is no standard and it’s up to the developer to define the level of UI accessibility.
I read, that you’re not allowed to talk about the application, so it’s rather impossible to help practically

#3

I will talk to the client again and see if I can convince them it makes sense to name the app in question. Needless to say, it is an extremely misbehaving app with a very poor implementation of any kind of applescripting - UI or otherwise.

I just discovered this same issue again with Accessibility Inspector & UI Browser, this time with something so simple I didn’t even expect it at all - the menu bar! It appears that UI Browser (and AppleScript) don’t return all the top-level menus in the menu bar. They only seem to return a “standard” set of menu bar items - File, Edit, Window, Help, etc. They don’t return the application-specific menus. Accessibility Inspector, however, does find the element and can act upon it (for example, select it to bring up the menu).

I must say, it’s extremely frustrating to know there is a way to do these things I want to do with UI scripting - someone’s already figured it out (via Accessibility Inspector) - but not to know how to implement it in applescript! :o

#4

Are you using Apple’s UI broswer or Prefab’s UI Browser? I prefer the Prefab product when working on these kinds or projects.

FWIW, I ran into Menu and GUI wierdness with Adobe’s print dialog boxes in CS2…most annoying.