Front Window Analysis Tool Using AppleScript System Events (List UI Elements)

See: Window Analysis Tool for System Events v1.5 in post #14.

Hey Folks,

This macro gets a bunch of information about the front window in the front application (specific to System Events UI-Scripting).

At present this is raw information that won't be very readable by the uninitiated, although I'll probably change that in time by finding and replacing the chevron-codes with their English equivalents.

Fixed in version 1.5 below.

The purpose of the macro is to discover whether System Events can see UI-Elements in the front window. This is very useful, because System Events can see and do things Keyboard Maestro can't.


Updated: 2021/02/24 17:02 CST by @ccstone

Please see: The latest version (v1.5) uploaded by Chris on 2016/06/13.

Also see: The Hierarchical UI-Element View using Script Debugger.

Also see: Alain's mod to enable code folding in BBEdit.

Window Analysis Tool for System Events 1.00.kmmacros (3.5 KB)


How is this different from your other macro (which I use, by the way)?

Hey Dan,

Front window only in the Front application. No need to designate an app – just have it frontmost.

I’m also getting the entire contents of the window – not just its properties – so we’re looking at all the UI-Elments of the window


[ Edited: 2016/06/12 06:36 CST ]

1 Like

Thanks for sharing, Chris.

You can count me in the group of “uninitiated”. :wink:
Your report reminds me of the first time I did a hexadecimal dump – OK, now what?

I can understand the potential. We will probably need some help in translation and usage.

Since you can get all of this info in a better format from UI Browser, do I assume correctly you are just trying to offer an alternative?

Oh, one thing. It opens the text file in TextEdit, even though my default app for “.txt” is TextWrangler.

What, you can’t read hex? Come on!

I still remember laughing when I saw a Z28 with a license plate that was (I think this is right) “5AF2F8”, which again IIRC is EBCDIC for “Z28”. The EBCDIC numbers were the giveaway, since they start with “F”. Back in the day when EBCDIC was still a thing.


It’s like some of my other skills – use it or lose it. :frowning:

1 Like

Uh, that’s not the only difference. The other macro produces results that make sense to me. This, as @JMichaelTX said, takes me back to reading HEX dumps. No, that’s not right - reading assembly language. I’ll bet there’s some NOP and HCF codes in there somewhere!


Hey JM,

I’m not offering an alternative – more like a litmus test (although there is potential for more than that).

99.9% of people won’t use the UI Browser utility, because it’s too expensive and/or too intimidating.

This macro gives me a diagnostic tool that anyone can use by pressing a keyboard shortcut.

By looking at the report I can immediately have a pretty good idea of whether or not GUI-Scripting is possible for the given window in the given app.

That’s because there’s a big difference between the -f and -t options in the shell’s open command.

-t looks at Launch Services to figure out what editor is set for text files “in the Finder”.

It also takes input from STDIN, which is why I used it in this instance.

-f looks at the default editor in the shell’s setup files. By default that’s TextEdit.

You change it you need to add a line to your ~/.profile (or other shell configuration file).

export EDITOR="/Applications/Applications_Chris/Text_Editors/BBEdit/";
open -f "/posix/path/to/the file.txt" # Input is a posix-path *not* STDIN.


Chris, I’m glad you can, but I’m not sure the rest of us could. :wink:

Any chance you could work your RegEx magic and produce a simple statement at the top as to whether or not the window is GUI-scritable?

If so, a report like the one UI Browser produces would be really helpful.

Here’s an example:
EN Mac 6.6 UI Elements.txt

Here’s a related script from that I have used a few times.
The output is readable.

Coerce GUI scripting information into string?

Hey Folks,

Updated to version 1.01.
Now requires Yosemite or greater.

It's faster and many of the chevron-codes are now replaced with human-readable names. (There are a lot of codes, so I certain to have missed some.)

I've added a property at the top of the script that allows switching the output between TextEdit and the default text editor set in the Finder's Get-Info dialog. (If you haven't changed it on your system then the default is TextEdit.)


Window Analysis Tool for System Events v1.01.kmmacros (7.3 KB)

1 Like

Sow how long before it can generate AppleScript or JXA code to manipulate these things?

Just kidding. Well, kind of, anyway. Welcome to Peter’s world of “it’s never enough”. :stuck_out_tongue:

«class splr» 1 of splitter group 1

is one of this in Path Finder

Chris, do you look for such feedback?


Hey Folks,

Changes to this version (1.50):

  • Faster.
  • No more chevron-codes to worry about.
  • Hierarchical view.

In my opinion BBEdit (or its freeware sibling TextWrangler) is a better vehicle for viewing this output than TextEdit. One reason for this is the ability to turn on “Show Tab Stops”, which makes the view of the hierarchy clearer (some other programming editors also have this feature).


Window Analysis Tool for System Events v1.50.kmmacros (7.6 KB)


Hey Alain,


But that version is obsolete now.  :sunglasses:


I cannot stop me to show an example of use of this so nice tool (I have needed) for UI players:


Here's what it looks like with “Show Tab Stops” turned on instead of “Show Invisibles”.

You know, it's funny you posted this. I was wondering today if there's any sort of native way to display hierarchical data on the Mac. For example, here's the plist view from Xcode:

Another possibility would be to output XML. Most browsers support reading XML and collapsing nodes, etc. I could probably shake the dust off my XML skills if you needed help.

In any case, great work!

Scratch that. Atom has a decent collapsible view. Good enough.

Hey Dan,

Interesting thought.

Here's how it looks in Script Debugger.

tell application "System Events"
   tell application process "TextEdit"
      front window
   end tell
end tell

I'm not going to fiddle with transforming it to XML at the moment, but I have an osax that might make that easy – so I'll think about it.

I'm not aware of any freeware hierarchical viewers for the Mac other than Xcode. I have a great utility called PlistEdit Pro that's much lighter weight than Xcode (but also more expensive).