Re: Why o why won't my script/app open? - solved (it's sneaky)
Re: Why o why won't my script/app open? - solved (it's sneaky)
- Subject: Re: Why o why won't my script/app open? - solved (it's sneaky)
- From: Paul Berkowitz <email@hidden>
- Date: Fri, 02 Nov 2001 09:39:24 -0800
On 11/2/01 4:26 AM, "Charles Arthur" <email@hidden> wrote:
>
I've reported this to Apple as:
>
"script editors do not resolve the names of OS X-based Apple scripting
>
additions to their Classic equivalents, due to the difference in name
>
between the OS X and Classic additions. If you are connected to a network
>
there is likely to be a very substantial delay on a Classic-only machine
>
in compiling or decompiling a script or application which was produced on
>
an OS X-based machine and uses its scripting additions. The delay is caused
>
by the script editor searching for a scripting addition with the suffix
>
'.app'."
It's not the script editor. The script editor plays no part in this. It's
AppleScript (or something deeper) itself which puts up the "Where is URL
Access Scripting.app?" message. Although you may have it an OSX
ScriptingAdditions folder, it's not a scripting addition (which would have
the suffix ".osax', not ".app"), it's an application. And an OSX
application, as you say, at that. Classic cannot find any OS X applications:
it's made not to. Can Classic find any of your other OS X applications? No.
Scripts running in OS X will look for apps with both the "app" extension and
without, and inside packages as well. that's why 'choose application' (as
used also by your Smile script editor when you ask it to find dictionaries
or target apps) gives you the full list of applications, some denoted as
"Classic Application" and some not. But the OS 9 system can't see any of the
OS X '.app' apps. If you use 'choose application' in OS X, you will see that
there's only one 'URL Access Scripting' listed and it's denoted as an
Application, with no mention of any other 'Classic Application'. That's
because the OS 9 System Folder (or maybe just the OS 9 Scripting Additions
folder) seems to be the on place OS X won't look. So the two are really
separate here.
Applications (especially Apple ones, but you can put any apps there) are
put in the Scripting Additions folders of OS 9 and X so that their
application keywords will compile on everyone's machine, if everyone also
has the application there. But the two systems are indeed different.
What might work would be to script:
tell application "Finder"
set urlAppPath to (application file id "uasc" as alias) as string
end tell
tell application urlAppPath
--your commands here in raw code , e.g. <<event aevtdwnl>>
end tell
using the proper chevron notation (opt-\ and shift-option-\) instead of <<
>
> which this mailing list server would muck up. You can find the raw codes
via both Script Debugger (in the Dictionary, switching the popup to Apple
Events) and Smile (see the Help). If you don't know how to do it smile, ask
here.
urlAppPath will be defined correctly in both OS 8/9, OS X and Classic. In
fact, if you know that he script will never be used on a computer running a
system earlier than OS 9, you don't even need raw codes:
tell application "Finder"
set urlAppPath to (application file id "uasc" as alias) as string
end tell
using terms from application "URL Access Scripting"
tell application urlAppPath
download -- some URL
end tell
end using terms from
Anyway, it's not a bug. Just something you have to work around if trying to
write scripts cross-system.
--
Paul Berkowitz