FROM : Bill Cheeseman
DATE : Thu Aug 05 17:39:20 2004
on 2004-08-04 11:57 AM, Stiphane Sudre at <email_removed> wrote:
> If the application is running and you send a quit and then activate,
> the activate fails.
Bear in mind that 'activate' does not launch the target application, but
only brings it to the front. It's the 'tell' statement that performs this
task, executing an implicit 'run' command. You can also use 'run application
"lambda"' before (or without) the 'tell' block, just to make it start
running. The 'run' command will launch and fully initialize it
Alternatively, you can us the 'launch' command, which will launch the target
application but leave out some normal startup steps such that, for example,
script statements addressed to it won't work if they include terminology
unique to lambda (as opposed to generic AppleScript terminology; the utility
of launch is that it doesn't present the target application's splash
screen).
So, in addition to my separate suggestion that you try relaunching it with a
Finder 'open application "lambda"' statement, you could try 'run application
"lambda"' at the beginning of the second script, followed by a 'delay'.
> So my conclusion is that the AppleScript engine is supposing the
> application is still there after the quit and that no human soul would
> think about relaunching it in the same script. Therefore it's using the
> cached connection.
This is entirely possible. There is a known, similarly elementary bug in
-[NSAppleScript executeAndReturnError:], whereby it fails to save script
properties that are changed during script execution (property values in
scripts are supposed to be persistent, saved in the script file itself). If
a very long 'delay' command at the beginning of the second script doesn't
cure your problem, then this is probably the correct diagnosis.
And, I just discovered, you can create a similar bug scenario in Script
Editor. I just compiled and ran a simple script addressed to iTunes. It
worked. Then I quit iTunes and edited the script (still addressed to
itunes). When I tried to compile it, I was surprised to get an error message
saying "The application is not running." When I then launched iTunes from
the Finder and tried to compile the script again, I was even more surprised
to get the same error -- even though iTunes was now running.
--
Bill Cheeseman - <email_removed>
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Thu Aug 05 17:39:20 2004
on 2004-08-04 11:57 AM, Stiphane Sudre at <email_removed> wrote:
> If the application is running and you send a quit and then activate,
> the activate fails.
Bear in mind that 'activate' does not launch the target application, but
only brings it to the front. It's the 'tell' statement that performs this
task, executing an implicit 'run' command. You can also use 'run application
"lambda"' before (or without) the 'tell' block, just to make it start
running. The 'run' command will launch and fully initialize it
Alternatively, you can us the 'launch' command, which will launch the target
application but leave out some normal startup steps such that, for example,
script statements addressed to it won't work if they include terminology
unique to lambda (as opposed to generic AppleScript terminology; the utility
of launch is that it doesn't present the target application's splash
screen).
So, in addition to my separate suggestion that you try relaunching it with a
Finder 'open application "lambda"' statement, you could try 'run application
"lambda"' at the beginning of the second script, followed by a 'delay'.
> So my conclusion is that the AppleScript engine is supposing the
> application is still there after the quit and that no human soul would
> think about relaunching it in the same script. Therefore it's using the
> cached connection.
This is entirely possible. There is a known, similarly elementary bug in
-[NSAppleScript executeAndReturnError:], whereby it fails to save script
properties that are changed during script execution (property values in
scripts are supposed to be persistent, saved in the script file itself). If
a very long 'delay' command at the beginning of the second script doesn't
cure your problem, then this is probably the correct diagnosis.
And, I just discovered, you can create a similar bug scenario in Script
Editor. I just compiled and ran a simple script addressed to iTunes. It
worked. Then I quit iTunes and edited the script (still addressed to
itunes). When I tried to compile it, I was surprised to get an error message
saying "The application is not running." When I then launched iTunes from
the Finder and tried to compile the script again, I was even more surprised
to get the same error -- even though iTunes was now running.
--
Bill Cheeseman - <email_removed>
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| Stéphane Sudre | Aug 4, 17:34 | |
| John Spicer | Aug 4, 17:56 | |
| Stéphane Sudre | Aug 4, 17:57 | |
| Stéphane Sudre | Aug 5, 14:42 | |
| Bill Cheeseman | Aug 5, 17:13 | |
| Bill Cheeseman | Aug 5, 17:39 |






Cocoa mail archive

