Re: Calling an application
Re: Calling an application
- Subject: Re: Calling an application
- From: JollyRoger <email@hidden>
- Date: Sun, 11 Feb 2001 17:25:56 -0600
on 2/11/2001 4:35 PM, Andrew Wylie at email@hidden wrote:
>
on 11 Feb 2001 13:54:55 -0600, JollyRoger at email@hidden wrote:
>
>
> I'll bite. :)
>
>
>
> -1713 is errAENoUserInteraction (No user interaction allowed). So it would
>
> seem that the app you were telling was not located on the same machine, and
>
> needed to display a dialog. If that is the case, then an error of -1713 is
>
> a perfectly normal and valid response. You can't provoke via a script user
>
> interaction (a dialog) on another machine.
>
>
No not on another machine, on a desktop other than the startup disk.
Then it may be a bug in Mac OS, AppleScript, or both.
Nevertheless, the behavior you are describing is exactly the behavior one
gets when you provoke user interaction on another machine.
You have to admit this is a strange place to store applications. Why are
you storing apps on desktops other than the startup disk? And why would you
not move the app to a better location to solve this problem?
>
> Why doesn't this result in the "Where is app?" dialog on your particular
>
> setup? Because the Finder was able to locate an app a) with that creator
>
> and b) with the same name as the app you made reference to when you compiled
>
> the script. If either of those changed, however, even the script you
>
> provided will display the "Where is app?" dialog.
>
>
a) yes b) no, I tested (AS1.3.7 OS8.6) deleting, moving (to other disks) and
>
renaming the app which caused no problem for either method apart from the
>
aforementioned -1713 for double tell.
Now move that script to another machine, and watch it break (display the
"Where is app?" dialog). :)
>
> Is your goal to prevent ANY "Where is app?" dialogs from being displayed?
>
>
yes with distributed compiled scripts.
Then I hate to be the bearer of bad news; but you are going to have to heed
our advice, and stop being so hard headed. ;) Some of us (including me)
have been distributing scripts world-wide for years, and know what works,
and what doesn't.
>
> If so, then about the only thing that really works in ALL situations is the
>
> "raw event code" method.
>
>
nasty?
Works?
If you are looking for an apology for it being nasty, don't look here - I
didn't make it that way - but I know it's the only thing that really works
for distributed scripts. :)
>
> double tell
>
>
ha! I was afraid to ask, the only explanation of this method I've read
>
didn't sink in though I'm sure it was no fault on the part of the author.
I won't bother trying to teach you why double-tell partially works, because
it only partially works, and you do seem to want something that works in all
situations.
If you want a complete solution that will never present the "Where is app?"
dialog, you're going to have to use the raw event code method. If you are
interested in learning how to do that, just say so, and someone will show
you.
>
On 11 Feb 2001 12:13:44 -0800, Paul Berkowitz at email@hidden wrote:
>
>
> I'll see if I can dig the URLs out from somewhere. Or maybe someone else can
>
> beat me to it.
>
>
thanks Paul, I've since read Bill's informative Sourcebook piece on the
>
subject and summise the only good reason to use double (or triple) tell with
>
AS 1.3+ is if you want to avoid some undesirable launch behavior in the
>
target app.
It's "surmise". And you have surmised incorrectly. The double-tell serves
to prevent/circumvent the "Where is app?" dialog in the most popular
situations - but not in all situations.
Just a note: You may not be aware of this, but you come across as being
slightly hell-bent on rebuking what people "in the know" are telling you -
that's not going to get you very far here.
JR