RE: AppleScript waits until the application returns a result
RE: AppleScript waits until the application returns a result
- Subject: RE: AppleScript waits until the application returns a result
- From: "Anderson, Bob" <email@hidden>
- Date: Fri, 30 Nov 2001 10:48:18 -0500
- Thread-topic: applescript-users digest, Vol 2 #1349 - 8 msgs
I can think of a very good reason for an application to
return immediately from a command. One application
we wrote would take 10 minutes or more to complete a
Apple event.
We did not want to set the timeout to an enormous
value to compensate: should the application hang up,
the script and the whole machine would be hung.
So we had our application return immediately and
provided an Apple event to return the busy status.
The AppleScript program would then use an idle
handler to poll the program to check for completion.
Nowadays, one could do this in a repeat loop containing
a delay command:
tell application "myprogram
repeat until (busy is false)
delay 1
end repeat
end tell
In this way, the AppleScript program and other applications
continue to function normally during Apple events
that take a long time to complete. And there is
no need to modify the timeout value.
---------
Another thing we did that was useful was to provide
an Apple event to lock the user interface. This prevented
the user from interacting with the scripted
program while it was executing a long command.
FYI: This application was called the DSCVerifer, a
PostScript file analyzer.
Regards,
Bob Anderson
>
Message: 5
>
Date: Thu, 29 Nov 2001 19:42:05 -0800
>
From: Chris Nebel <email@hidden>
>
>
This is a popular belief, but is not generally true. AppleScript waits
>
until the application returns a result from the command [1]. If the
>
application returns before it's actually done doing whatever you asked
it
>
to, there's nothing AppleScript can do about that. It's considered bad
form
>
to write an application this way, but some people do it anyway [2].
>
>
>
--Chris Nebel
>
AppleScript Engineering
>
>
[1] unless you use "ignoring application responses", in which case it
>
doesn't wait.
>
[2] In their defense, sometimes they don't have a choice.