Yes, but it's been done. 
OK, I think I understand now.
System Events has a number of commands/properties that can be applied to ALL app processes, right?
For example:
frontmost (boolean) : Is the process the frontmost process
That is what wasn't clear to me in your BBEdit examples.
But it is now, I think. 
Thanks for your help and patience. I think our discussion could be of big help to others interested in scripting.
Sure there are a number of AppleScript books out there, but none that are really recent.
The key, I would think, is to have a format that is different, that is easier for the new AppleScript coder to learn.
Maybe instead of a book, an online study course?
Hey JM,
Yes. That's why I pointed you to the application process class in the System Events dictionary.
Would it have been more clear if I'd said:
tell application "System Events"
tell application process "<the-process-name>"
set theAppIsScriptable to its has scripting terminology
set theAppsUnixID to its unix id
end tell
end tell
Or perhaps:
tell application "System Events"
set theApp to first process whose bundle identifier is "com.barebones.bbedit"
tell theApp
set theAppIsScriptable to its has scripting terminology
set theAppsUnixID to its unix id
end tell
end tell
-Chris
1 Like
The challenge is always for the master to use terms the grasshopper can understand. When you know something really well, it is often hard to describe it in terms the uninitiated can understand, or can quickly learn.
Pointing me to application process is OK, but, IMO, this is crystal clear:
System Events has a number of commands/properties that can be applied to ALL app processes
Then, the "application process class" makes a lot more sense.
Anyway, thanks for your patience and taking time to explain things to me. Like I say, hopefully this will benefit a lot of others as well.
Hey JM,
Absolutely true, but it is also incumbent upon the student to do their homework.
You have to know what an application is — a variable — a list — a class — a property — an element...
Vocabulary is critical to communication.
I looked and found that System Events is not even described for what it is and does in the Applescript Language Guide.
I'm beginning to think I'm going to have to build my own wiki...
-Chris
Agreed.
Here is what is interesting to me about System Events.
I have actually done a lot of research and reading on AppleScript, including the so-called master book The Comprehensive Guide to Scripting and Automation by Hamish Sanderson.
Yet I have never learned what I learned today about System Events.
Maybe it was in there somewhere. If so, it didn't stick.
I just did a search on my Kindle book, and here is the best description of System Events I could find:
System Events is what's known as a “faceless background application"—a GUI-less program that runs invisibly on your Mac.
I could not find anything on using System Events with app processes.
In “AppleScript: Developer Reference” by Mark Munro:
There’s a whole chapter on System Events (about 23 pages). It’s not comprehensive, but it’s a reasonable start.
“System Events is a faceless, background application that makes many Macintosh Operating System (Mac OS) X features scriptable. It contains 23 suites of commands that extend AppleScript’s reach into many system preference settings. System Events also enables a developer to access the user interface elements of any application, including those that do not provide any scriptable dictionary commands.”
I’m very disappointed in what the “Learn AppleScript” by Hamish & Hanaan book has to say about System Events and GUI-Scripting in general.
-Chris
Do you think this is the best AS book?
No. I don't think there is a best book, however to be fair I have not had my hands on two or three of the newer ones.
This book has its points, but so does the Hamish & Hanaan book — and even though it's old now Matt Neuburg's has some good stuff in it.
-Chris
###Let's create a better KM Variable Creation handler...
This handler passes an AppleScript record as a parameter.
Using a record this way greatly improves the clarity of the values being passed in the handler-call, therefore it is more readable and a good deal safer.
In the previous handler's calls you have to infer which is the variable name and which is the variable value. If your handlers like mine are hidden in a library it's very pesky to have to open the lib and find the hander to see what the parameters are and what order they're in.
------------------------------------------------------------
# Setting KM Variables in AppleScript usin a Record.
------------------------------------------------------------
setKMVar({varName:"Test1", varValue:"I am nuts!"})
setKMVar({varName:"Test2", varValue:"Or am I?"})
------------------------------------------------------------
--» HANDLERS
------------------------------------------------------------
on setKMVar(varRec) -- Record Format: {varName:"text", varValue:"text"}
set {varName, varValue} to varRec's {varName, varValue}
tell application "Keyboard Maestro Engine"
try
set value of variable varName to varValue
on error
make new variable with properties {name:varName, value:varValue}
end try
end tell
end setKMVar
------------------------------------------------------------
-Chris
2 Likes
###System Events & GUI-Scripting
One of the powerful features of the System Events.app is the ability to do GUI-Scripting.
What is GUI-Scripting you ask?
In essence well constructed applications on OSX use certain application program interfaces or (APIs) and follow certain design guidelines — when an app follows the rules (so to speak) the system is able to see the building blocks from which it is made.
Thus OSX can access the GUI (Graphical User Interface) of many apps to one degree or another via AppleScript and the System Events application.
GUI-Scripting is not for the faint-hearted. It takes time, effort, and patience to puzzle out the often Byzantine complexity of UI-Elements to reach the one you want to work with.
Without good tools gui-scripting can be extremely difficult, and there is never a guarantee that you can accomplish the task you want to accomplish. You have to poke, and prod, and tinker to see if you can do what you want.
The two primary tools available are Accessibility Inspector.app (free) and UI Browser.app (commercial).
Apple's Accessibility Inspector.app is a tool every gui-scripter should have. To acquire it you need to download Xcode from the app-store.
A much more sophisticated and easier to use tool is [**UI Browser.app**][1] from [PFiddlesoft][2].
At $55.00 U.S. it is a tool for professional scripters and power-users — but I assure you I've never regretted spending the money — UI Browser has kept me from pulling my hair out many, many times.
In this image you see UI Browser highlighting the editor panel of the KM forum I'm currently writing this post in. With a keystroke and some patience I was able to reach through the hundreds of elements of the forum page and get to the item I wanted. (Patience because it took time for UI Browser to wade through all those elements and get to its final destination — with something less complicated there is rarely much waiting.)
Tools don't get the job done by themselves — the tool-user has to learn how to use them.
When is a push-cut the way to go... When is a draw-cut is the way to go... What are the key differences in working with softwoods or hardwoods...
Unfortunately there are no clear cut manuals for how all this works. Some of the AppleScript books on the market cover GUI-Scripting basics, but there's no comprehensive reference out there anywhere I know of.
(Caveat — I have not had my hands on "Apple Training Series: AppleScript 1-2-3" coauthored by Bill Cheeseman with Sal Soghoian. You would hope the subject would be well covered in that book, since Bill is the developer of UI Browser.)
Several times I've asked Bill to create a user-list or forum for UI Browser, but he's a busy man and has so far declined.
There is a lot of information on the Internet about GUI-Scripting but no resource I know of is methodical and well organized. Maybe it's time to start one...
-Chris
3 Likes
Wow! That's a great, informative, write-up, Chris! 
Thanks for taking the time to write it and to share it will all of us.
I have EverNoted it for future reference.
For a concrete example, I just want to reference the code Chris posted earlier on using System Events with Mac Mail. It works great.
See this post:
###How To Install AppleScripts/JavaScripts for Dummies
Hey guys, I’m looking for a web page I can give to users who know nothing about AppleScript. It need to provide clear, step-by-step instructions on where to save the AS, and how to enable the AS menu if it is not there.
I have searched and searched, but can’t find such an animal that’s not buried in an article.
I could write one, but I hate reinventing the wheel. 
Do you have any suggestions?
There's nothing good, well organized, and comprehensive.
Probably the best single site is MacOsXAutomation.com which is run independently from Apple by Sal Soghoian — Apple Product Manager — Automation Technologies.
Shane Stanley also contributes to that site.
Despite my appreciation for both of them I'm not in love with the site, and the way it presents content.
This has been going on for years now, and the only way it will change is if I or someone like me decides to tackle it independently. I would have done it years ago if I had more time and energy.
-Chris
Thanks, Chris.
This is for users of AppleScripts, not developers.
Most of them just want to use the script I provide without understanding any of the tech stuff. So I need it simple, not comprehensive. Step 1, 2, 3.
This is the best have found so far, but it's a bit dated:
How to Install an AppleScript
I guess if neither you nor Rob know of anything better, I'll just bite the bullet and write one. I'll probably just publish it as a public Evernote note (accessible if you have the URL, but isn't found by search engines).
Hey JM,
That's very poor indeed.
Worth noting is:
But something more generic and clear is desirable.
The Apple Script-Menu is now enabled/disabled via the AppleScript Editor.app preferences.
I always recommend that people use FastScripts in preference to it though. As far as I know it will work with unlimited scripts in free-mode, but only 10 Hot-Keys will be allowed. Paid-mode enables unlimited global and app-specific Hot-Keys.
You could test that for me if you would — I don't want to disable my license and risk losing anything.
You want an up-to-date picture of the Script Editor, and you'll want to show what the Apple Script-Menu (or FastScripts) looks like in the Finder menu-bar.
I would also mention Keyboard Maestro at this point for people who might want to do more than run AppleScripts (and shell scripts).
I usually provide a script to open the scripts-folder, so I don't have to field too many questions — and the user has a nice simple little toy to play with in the Script Editor.
---------------------------------------------------------------------
# Assemble relevant folders & paths.
---------------------------------------------------------------------
set userLibraryFolder to path to library folder from user domain
set userAppleScriptFolder to (userLibraryFolder as text) & "Scripts:"
---------------------------------------------------------------------
# Open the user-scripts folder in the Finder
---------------------------------------------------------------------
tell application "Finder"
activate
try
open (userAppleScriptFolder as alias)
on error
make new folder at userLibraryFolder with properties {name:"Scripts"}
end try
end tell
---------------------------------------------------------------------
It's been a while since I've written this stuff up, but I've done it 300 times over 20 years — and yes it gets tedious.
I used to have a pretty good canned writeup before I got burgled some years ago.
-Chris
1 Like
That's very cool. It wouldn't take much more to turn it into a full installation script, allowing the user to select the script file and then put it in the right location.
The final step would be to turn it into an app.
Or am I reinventing the wheel here.
Should I just get a DMG creator?
Applets these days have to be code-signed to run on someone else's machine.
I used to send people double-clickable installers or drag&drop installers for things when they were computer-challenged, but I haven't messed with that for a few years.
I really need to renew my developer license, so I can code-sign apps — but the last time I tried Apple messed with me and ticked me off. I need to get over it and get on with it.
What specifically did you have in mind?
I own DropDMG and have kept it current pretty much since it came out, but it doesn't have any built-in install capability. To do that you'd have to build an installer pkg, and those probably have to be code-signed too.
I'm not sure how a applet on a DMG would behave. I suppose I could make up a dummy and send it to you to let you try.
-Chris