Re: Who called?
Re: Who called?
- Subject: Re: Who called?
- From: email@hidden
- Date: Wed, 17 Jan 2001 00:00:42 -0500
On Tue, 16 Jan 2001 14:39:09 -0500, Dave Saunders <email@hidden>
asked,
>
So, what I want to do is:
>
>
try
>
blah...blah...blah
>
return "OK"
>
on error
>
if OneClick called me then
>
return ErrorMsg
>
else
>
display dialog ErrorMsg
>
end if
>
end try
I do a similar thing for scripts that I call from ListSTAR Server (which can
compile and run scripts itself, or send events to script applications), so a
script can tell whether they are running from within ListSTAR, as its own
applet, or with Script Editor. Here's the code I use.
tell application "Finder" to set myBoss to creator type of (path to me)
if myBoss is "aplt" then -- running as an applet
--
else if myBoss is "*9EM" then -- compiled script by ListSTAR
--
else if myBoss is "ToyS" then -- running inside Script Editor
--
else
-- who knows who's the boss.
end if
This way, I can run a self test when inside Script Editor and return a self-test
value to the result window, but give the return code ListSTAR wants if the
script (as an applet) get a message from ListSTAR, and if the script is compiled
by ListSTAR, send myself the same event the applet would receive.
The only place where this fails is in Smile. If you save a script as a script
application in Smile (or edit an existing script application), it makes "path
to" return the path to the script application on disk, and not the path to
Smile. This is usually good, since you can test a script application and it
will behave the same under Smile as when its running for real. (In fact, that's
often why a script needs to know under what environment it is running. For
example "log" and "quit" work differently (specifically, "log" works in Script
Editor and "quit" doesn't, while "log" fails and "quit" works in an applet.)
But it makes my handy self-tests not run.
This will work if OneClick runs the compiled script for you. But if it just
sends a "run" event to your script application, you won't be able to tell that
OneClick and not the Finder sent the message from within the script. The
solution in that case is to create a helper script, that will be invoked by
OneClick, and pass that fact on to the main script.
So you modify your main script so it has two entry points.
property caller : "User" -- default. Changed if OneClick calls.
on run
try
blah...blah...blah
return "OK"
on error
if caller is "OneClick" then
return ErrorMsg
else
display dialog ErrorMsg
end if
end try
end run
to RunForOneClick()
set caller to "OneClick"
tell me to run
set caller to "User" -- set it back, so next time if the user runs, we're OK.
end OneClickEntry
on quit
set caller to "User"
continue quit
end quit
Now, instead of having OneClick call this script, have it call the helper script
on run
launch application "That other script"
tell application "That other script" to RunForOneClick()
end run
You have to launch the script before sending it the message. If you don't
launch it, AppleScript will "run" it before sending it the RunForOneClick
message, and you'll get a double invocation.
If you think this limitation is a problem, change the main scripts "Run" handler
name to "to RunForUser()", write an interface script for the user as well, and
move the common code to its own handler. You will have a more symmetric main
script, without concerns that may end up with the "Caller" property storing
"OneClick" when the script is ready to run. (This is what the "on quit" handler
above is doing. If an error occurs, the quit handler runs and you get a chance
to set the property back to "User". But its not needed with a two-handler,
two-helper solution.)
So, here is the main script
property caller : "User" -- default. Changed if OneClick calls.
on DoTheJob()
try
blah...blah...blah
return "OK"
on error
if caller is "OneClick" then
return ErrorMsg
else
display dialog ErrorMsg
end if
end try
end run
to RunForOneClick()
set caller to "OneClick"
DoTheJob()
end OneClickEntry
to RunForUser()
set caller to "User"
DoTheJob()
end RunForUser
The interface scripts are simply,
-- User interface
on run
tell application "Main script" to RunForUser()
end run
The user will double-click this interface script, while OneClick will go in
through its helper script, which can now just be,
on run
tell application "Main script" to RunForOneClick()
end run
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden