I am not the right person to answer, but personally, I tend to use of it, instead of its at least when concious, like the same way I use get, probably a lot more than I should!
This is a corrected version of the script I posted in post # 10, the getting of setting of application process properties are reversed here, so that it works as anticipated. I am not sure if it is due to some new behaviour of Mavericks, but now at least, this is the way to do it.
-- revised 2013.11.23
-- http://www.macscripter.net/viewtopic.php?pid=25133#p25133
tell application "System Events"
tell (first application process whose frontmost is true)
set active_name to name of it
set visible of it to false
end tell
set Name_App to item 1 of (get name of processes whose frontmost is true and visible is true)
end tell
tell application active_name
activate
display dialog "previous active app: " & Name_App
end tell
I don’t think you need to use System Events for that from Leopard (10.5) onwards:
set nm to name of application (path to frontmost application as text)
By the way, I have just discovered, that the creator typ of an application, is what you really use for application id, and not bundle identifier. At least is is most robust.
if you call an application in a loop, then using application id, instead of application (name), should save the execution, of at least 1000 lines of C code per call. (You short circuit the work of getting the path to the application by launchd then.)
Well, it actually worked, telling application id “bundleidentifier” failed.
You may not notice the time time, but the truth is, is that the operating system may be relieved of some work, and that is allways a good thing, I wrote in a loop, and I don’t see the any point of having the operating system perform a really uneccessary action for every iteration of the loop.
I may hope compiled C code; machine code. besides that, a good hash table is only a few lines of code.
Application by name or (bundle) id is as different as searching a mail by subject or sender. The search will only be done by different strings on different columns in the database. Depending on the indexing of the database, which with no doubt will be fine, there is no difference between finding an application by it’s name or bundle id.
There is actually a difference as I have understood it. Using the application name, is similar to using the just a command name in a shell script, launchd will resolve the path of the command by searching for it, taking height for verson numbering here and there, which copy of the app is to be addressed by the name etc.
Using bundle id, or creator type, short circuits all that, and can be viewed, as specifying a command with an absolute path in a do shell script.
That is my understanding, and then, when you know the creator type, then you see the advantage if you are iterating some times, if not just for the principle, of not doing unecessary operations.
From where I understand it is not the version number but the AppleEvent manager will send it’s event to the first running process. To get running processes by job or by name from the process database (manager) is imo equally fast.
If the process isn’t running then it uses launch services’s meta database. In this database (you can see it when you dump it) the bundle id, name or creator code have all the same multiple values. In here there is still not another record having more advantage of the other. So when I look for org.mozilla.firefox for example, I will see all the version loaded from teh downloaded DMG files and installed versions, if I look by bundle id or name.
Creator code is a no go because it’s old legacy code coming from Mac OS systems. It’s an last resort
While that is true, the two forms appear to take a different code route – when an app can’t be found, one generates the “Find app” dialog, while the other generates an error you can trap. One could be quicker than the other.
Even so, in a running app (that is, outside a script editor), I’d be very surprised if AS resolved it more than once for each app used. I find it hard to believe that in a repeat loop, AS would resolve it again each time through the loop.
One thing about using the name of a process is that some processes don’t use the same name as it’s application. That’s why I changed my process quitter to bundle identifier:
tell application "System Events" to launch
set my_name to my name
tell application "System Events"
set visible of every process to true
delay 0.5
set app_ids to (bundle identifier of every process whose visible is true and name is not "Finder" and name is not my_name)
end tell
repeat with app_id in app_ids
tell application id app_id to quit
end repeat
It’s not the running instance of AppleScript that communicates with the Application directly. It’s communication through the AppleEvent manager. That means the AppleEvent manager can’t predict how many times it needs to send an event to the application. Still I’m sure, much like you, that the AppleEvent manager has an clever way to resolve this.
I just wanted to add that I omitted to my first recommendation, that this technique should not be used with third party apps, but with Finder, TextEdit and such you are really on firm ground for applying it.
If I got a dollar for every time I thought better of the AppleScript by now, I am sure I could have bought two milkshakes in Norway. I mean that now, it would be natural if this stuff was cached some place wouldn’t it, if if it was looked up, but thing is, this is a run time environment, so I am rather thinking it will execute the find app call every time, since the user in theory may change name of it in between calls.
Easy enough to check. Write a script app like this:
repeat 1000 times
tell application id "blah.blah.blah"
-- some code in here
end tell
end repeat
where “blah.blah.blah” is the id. Then delete the app, but put a copy on an external drive.
Now run the script app, and when the “Find the app” dialog comes up, choose the copy on the external drive. If the dialog comes up another 999 times, you earned a milkshake. If it doesn’t, it’s being cached.