Re[2]: Script Applet rejects first handler call
Re[2]: Script Applet rejects first handler call
- Subject: Re[2]: Script Applet rejects first handler call
- From: email@hidden
- Date: Wed, 1 Aug 2001 19:06:58 -0400
On 8/1/01 9:53 AM, Deivy Petrescu <email@hidden> said,
>
At 9:52 PM -0700 7/31/01, Christopher Nebel wrote:
[...]
>
>
>
>Ah, no. This is a known bug in the applet shell that was introduced
>
>in AppleScript 1.6 and should be fixed in the next release. The
>
>only workaround (aside from dropping back to 1.5.5 or earlier) is to
>
>launch the applet first.
>
>
>
Not to contradict you, but according to AppleScript guide for 1.3.7 (page
310):
>
>
"Instead, the Tell statement launches the script application and sends it an
>
implicit Run command. The application handles that Run command.
>
AppleScript then gets to the explicit Run command in the calling script and
>
tries to send another run event to the script application. [...]
This passage is discussing what happens if you don't have a script application
saved as "Stay Open", and you try to send it an event. It gets the implicit
"Run" event, runs, exits, and then the handler event gets sent to the departed
application. Elvis has left the building.
The focus of the bug we're discussing is related to what's in the AppleScript
Language Guide just before the section quoted. There the Guide notes that a
script application handles events on a first-in, last-out manner. I've already
discussed why I think this model makes for trouble for the scripter, and a
first-in, first out queue would be nicer. But under 1.6, the problem is that
you get an error. Its not a problem with a handler call interrupting the run
call, but the script application responding to the handler call with a -1708
error (errAEEventNotHandled). I'm guessing that under 1.6, the applet shell is
responding to the "run" event before it has completed enumerating the script's
handlers.
The bottom line, for me, is that to call any application from an AppleScript,
you just use the command,
tell application "SurfWriter" to hang ten
The script writer shouldn't have to worry about waiting for the application to
start up and become ready for the next event, or check if it needs to be run
yet. It should just work. Particularly for script servers, CGI scripts, and
other "background engine" types of processes. The user may shut them down, or
they may die, or the may intentionally shut themselves down every few hours to
release resources, prevent memory leaks, or stop bit rot. There may be multiple
clients all trying to get service. Who's in charge of starting and stopping the
server? It should work the way it always has, with the server being started if
needed, and the clients free from the need to test and launch the server.
--
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