See: in post Window Analysis Tool for System Events v1.5 #14.
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 on 2016/06/13. latest version (v1.5) uploaded by Chris
The Hierarchical UI-Element View using Script Debugger.
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)?
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 ]
Thanks for sharing, Chris.
You can count me in the group of “uninitiated”.
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.
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!
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
-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).
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.
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
MacScripters.net that I have used a few times.
The output is readable.
Coerce GUI scripting information into string?
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)
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”.
June 13, 2016, 8:05pm
«class splr» 1 of splitter group 1
is one of this in
Chris, do you look for such feedback?
Changes to this version (1.50):
No more chevron-codes to worry about.
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)
But that version is obsolete now.
June 13, 2016, 8:41pm
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.
Here's how it looks in Script Debugger.
tell application "System Events"
tell application process "TextEdit"
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).