Re: Best practice for activation of another application
Re: Best practice for activation of another application
- Subject: Re: Best practice for activation of another application
- From: Paul Berkowitz <email@hidden>
- Date: Sat, 08 Oct 2005 09:53:31 -0700
- Thread-topic: Best practice for activation of another application
On 10/8/05 9:19 AM, "Daniel Jalkut" <email@hidden> wrote:
> When I write an AppleScript that needs to display a dialog in another
> application, I always explicitly activate that appliation first:
>
> tell application "iCal"
> activate
> display dialog "hello"
> end tell
>
> I've noticed that some scripts leave out the activate, and rely on
> the host application to decide whether the frontmost application is
> switched out or not (by controlling the execution flags of the
> AppleScript).
>
> I can see arguments for both practices. Explicit activation means
> that a particular user experience will always be obtained, while
> leaving the activation out could be perceived as less intrusive to a
> user or application who doesn't want to have their focus "hijacked."
As Michelle says, a dialog placed within a tell block to an application
appears in that application. What used to happen (in Classic and up to OS
10.1 or 10.2, I forget) was that if you didn't activate the app and it was
in the background, the dialog would appear there and would stay up until it
timed out, when it would error. Since about OS 9, you could add a 'giving up
after' parameter which could specify how long to stay up, then it wouldn't
time out or error.
What happens now (since Panther or Jaguar, I forget - Panther, I think) is
that if the app is in the background, the dialog doesn't actually appear
there: instead the app's icon starts bouncing up and down in the dock to get
your attention. You have two minutes, I think, to respond - if you don't the
script times out with an error. A 'giving up' parameter does not alter this
- what you need to do if you want to avoid this is put the 'display dialog'
inside a try block: you can specify a default behavior to occur 'on error'
if you wish, or just end the script.
So, what do you think is better in each circumstance is what you should do.
If the script is somehow running automatically according to some schedule,
or taking a long time to do its stuff, but you absolutely require the user
to answer a display dialog, you'll either have to activate the app. or let
the bouncing icon catch his attention (and maybe only activate in the 'on
error' with a new dialog there). If it's not absolutely necessary, perhaps
it's just an 'all done!" notification, I do this:
tell app "iCal"
try
display dialog "All done!" giving up after 86400 -- 24 hrs
end try
end tell
This way, if the app is in the front, the notice will stay up until he comes
back from his coffee break or sleep. If it's in the background, it will go
away after 2 minutes if he's not there to bring the app to the front or he
doesn't want to, and the script can complete without error. The 'giving up'
never actually comes into play, since the dialog never appears. When I set
preferences to allow for automatic run without disturbance, I do something
like this:
tell app "iCal"
try
display dialog "Choose" buttons {"1", "2"} giving up after 600
-- 10 min
if gave up of result then -- if in front
set someVar to "2"
else
set someVar to button returned of result
end if
on error -- times out in background
set someVar to "2"
end try
end tell
If you really need him to answer in order for the script to continue, better
beep and activate, or activate when timing out. To avoid the 'on error'
running when the user presses the Cancel button, you need to specify the
error number and deal with it one way or the other. "Cancel" is error number
-128, "AppleEvent timed out" is error number -1712.
--
Paul Berkowitz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden