You are not logged in.
Hi,
I am trying to write a script which references the current frontmost application window from a script on the Scripts menu. The trouble is when I do, the application "Script Events" becomes the front application, and I am unable to find a script which references my original app, which has now been relegated to second place!
I know it would be easy to reference my app by name ( e.g. tell app "Safari") , but I need the script to work generically for any frontmost app I am working in.
I suppose I want to re-activate my app to be frontmost again. But how exactly?
Thanks!
One mans trash is another mans treasure
Offline
Hello,
First of all, I have to confess two things: 1.) I am a newbie scripter myself, and 2.) I don't fully understand what it is that you wish to do ( also you should probably state what version of Script Editor and OS/X you are currently using). Secondly, are you familiar with what the keystroke combinations Command-tab & and Control-d (assuming you have activated them in System Prefs.) can do for you in terms of application switching? I apologize that I can't offer you more than the above at the moment and hope that this helps.
Sincerely,
Variable as the shade
Offline
Variable,
Thanks for replying. I'm using 10.3.2 and the latest Panther Script Editor.
I do know about these keys, but don't use them much. I figured that, if I didn't find a more elegant route, I would have to simulate these keystrokes using "System Events" - but using UI scripting always feels like a bit of a cheat!
Here's the problem again. I'm in an active window, and I want to run a script that starts by getting the name of the app which owns this active window. But when I start my script this target app is now no longer the frontmost app, because now another process has taken over to run the script - namely "System Events", (or "Script Editor" if I run the script from the editor window). I need to be able to reference this previous app in my code, but I haven't found a way to.
One mans trash is another mans treasure
Offline
This has been covered many times before on the board. A little searching would have turned up these threads (as well as others):
http://bbs.applescript.net/viewtopic.php?t=5874
http://bbs.applescript.net/viewtopic.php?t=4524
Jon
Offline
Jon,
First of all, many many thanks for the links - exactly what I wanted.
Secondly, as I stated, I am a newbie to scripting (hence the clearly flagged title) - but not to the etiquette and methods of forums. I have worked extremely hard not to bother more experienced users with this simple problem until I felt that I really needed help. I searched in many other places before coming to Macscripter. It is remarkable to me that such a basic element of scripting is not more widely documented.
Thirdly, I searched *extremely hard* on this forum for a post that would address this problem. I'm afraid that I didn't find anything, hence my post. As you will know, these things are often a case of forming a query in a site search engine that describes exactly what the problem is *in a manner of speech an earlier poster may have put it*. This is not always easy and even a random search gave me no results.
Lastly, as a new macscripter user making a first post, I cannot be privy to the knowledge that comes from long experience of using this forum. Repeated posts, however tedious to the expert, are still new to somebody. (Note that the previous responder to this query was also not aware that this problem had been asked before) I am a very experienced user on various other forums, and always try to bear this in mind.
One man's voyage of discovery is, I'm afraid, another man's source of irritation. That's why I place the word "newbie" in the title - so that those offended can choose to ignore it.
Many thanks.
One mans trash is another mans treasure
Offline
G'day
Dammit the links posted above are redundant. I've got the same dilemms, so if anyone would care to post an answer to the top question, I'd be grateful.
Santa
Just an enthusiastic old fart of an Apple user since the IIe days
Offline
maybe it works with a little trick.
In AppleScript’s own dictionary there is an "path to frontmost application" command.
Applescript:
set thePath to path to frontmost application as Unicode text
set oldDelims to AppleScript's text item delimiters
set AppleScript's text item delimiters to {":"}
set frontmost_app to text item -2 of thePath
set AppleScript's text item delimiters to oldDelims
frontmost_app contains the name of the frontmost application
[EDIT] or much easier:
Applescript:
set frontmost_app to name of (info for (path to frontmost application))
Model: G5 dual 2,5 GHz
Browser: Safari 419.3
Operating System: Mac OS X (10.4)
Last edited by StefanK (2006-10-25 05:22:39 am)
regards
Stefan
Offline
Jon8, above provided some tantalizing links to what appears to have been a solution to the vexing problem of determining the frontmost running application (the one most likely running the frontmost window on your screen). Unfortunately, Jon8's links don't work (as of 6-21-07). Therefore, I thought it might be helpful to show what I recall was the method to this useful task:
Applescript:
tell application "System Events"
set visible of (first application process whose frontmost is true) to false
set Name_App to item 1 of (get name of processes whose frontmost is true)
activate
display dialog Name_App
end tell
What this script does is to make your AppleScript window disapear (not close) and get the name of the front running process (application) running after the AppleScript. Note that your AppleScript will reapear if you activate it by clicking on the Script Editor icon.
"Practice is the best of all instructors"
Publilius Syrus
Offline
Thank you - I was wracking my brain to recall that, given that Jonn8 hasn't been around for a while.
Mac mini running 10.14.6, 2011 27" iMac as display.
Offline
Hello!
I have tinkered the code above a little, and this works for me, and that is just so great!
Now I can which process was the previous active one, i think this is a little bit better than ui scripting, not much, but a little!
Applescript:
-- [url]http://www.macscripter.net/viewtopic.php?pid=25133#p25133[/url]
tell application "System Events"
tell (first application process whose frontmost is true)
set visible of it to false
set active_name to name of it
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
Last edited by McUsr (2012-08-13 08:30:40 am)
Mercurial vcs is a joy to use for scripting.
Offline
Hello
I'm puzzled.
Why the script doesn't behave the same if I replace the instruction
set visible of it to false
by
set its visible to false
In this script borrowed from ApplescriptLanguageGuide « of it » and « its » behave the same.
Applescript:
tell application "Finder"
it --result: application "Finder" (target of tell statement)
set myFolder to path to home folder
--result: alias "Leopard:Users:myUser:"
files in myFolder --result: a list of Finder document files
files in myFolder where name of it contains "AppleScript"
(* result: document file "AppleScriptLG.pdf" of folder "myUser"
of folder "Users" of startup disk of application "Finder"}*)
files in myFolder where its name contains "AppleScript" -- same result
files in myFolder where name contains "AppleScript" -- same result
every file in myFolder whose name contains "AppleScript" -- same result
every file in myFolder where name of it contains "AppleScript"
-- same result
end tell
Yvan KOENIG (VALLAURIS, France) lundi 13 août 2012 17:12:25
Offline
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!
For all I know, it is a System Events quirk.
Last edited by McUsr (2012-08-13 09:56:49 am)
Mercurial vcs is a joy to use for scripting.
Offline
Thank you
I'm hitting a wall with the same kind of instruction.
As I'm curious, I tried :
Applescript:
tell application "Finder"
every folder of folder "Macintosh HD:usr:share:locale:" where name of it contains ".UTF8"
end tell
It returns {}
Yvan KOENIG (VALLAURIS, France) mercredi 15 août 2012 16:57:58
Last edited by Yvan Koenig (2012-08-15 09:58:38 am)
Offline
Applescript:
tell application "Finder"
every folder of folder "Macintosh HD:usr:share:locale:" where name of it contains ".UTF8"
end tell
It returns {}
Hi, Yvan.
Try '… whose name contains ".UTF-8"'.
NG
Offline
Hello Nigel
Thank
What fool I am ?
The problem wasn't the instruction, it was the searched string.
I dropped a dash and of course the code found nothing.
Yvan KOENIG (VALLAURIS, France) mercredi 15 août 2012 21:06:30
Offline
Hello.
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.
Applescript:
-- revised 2013.11.23
-- [url]http://www.macscripter.net/viewtopic.php?pid=25133#p25133[/url]
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
T.B
p a file peruser, work in progress, but is sane, and lets you copy the file you view to the clipboard. Enter just "p" for help. Slightly better terminal handling, when executing shell commands from within.
Offline
Hi McUsr,
In Mavericks, when I run this script:
Applescript:
tell application "System Events"
set fa to name of first process whose frontmost is true
end tell
display dialog fa
I get "Safari".
Os 10.10.3
Mbp
Offline
Hello.
I don't think you need to use System Events for that from Leopard (10.5) onwards:
Applescript:
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.)
T.B
p a file peruser, work in progress, but is sane, and lets you copy the file you view to the clipboard. Enter just "p" for help. Slightly better terminal handling, when executing shell commands from within.
Offline
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.
Except that it's deprecated, and lots of apps don't have a creator type.
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.
Which saves how much time exactly?
FWIW, I think this is a particularly bad piece of advice.
Shane Stanley <sstanley@myriad-com.com.au>
www.macosxautomation.com/applescript/apps/
latenightsw.com
Online
McUsrII wrote: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.
Except that it's deprecated, and lots of apps don't have a creator type.
Well, it actually worked, telling application id "bundleidentifier" failed.
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.
Which saves how much time exactly?
FWIW, I think this is a particularly bad piece of advice.
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.
T.B
p a file peruser, work in progress, but is sane, and lets you copy the file you view to the clipboard. Enter just "p" for help. Slightly better terminal handling, when executing shell commands from within.
Offline
that is allways a good thing
Not when it means writing code that's likely to break in future, IMO.
Shane Stanley <sstanley@myriad-com.com.au>
www.macosxautomation.com/applescript/apps/
latenightsw.com
Online
Hi McUsr,
I thought you were responding to the original posters post about running scripts from the script menu. I was confirming that it now works right.
Have a good day,
kel
Os 10.10.3
Mbp
Offline
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.)
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.
Offline
McUsrII wrote: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.)
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.
Last edited by McUsrII (2013-11-23 08:15:15 pm)
T.B
p a file peruser, work in progress, but is sane, and lets you copy the file you view to the clipboard. Enter just "p" for help. Slightly better terminal handling, when executing shell commands from within.
Offline
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
Last edited by DJ Bazzie Wazzie (2013-11-23 08:22:59 pm)
Offline