Hello,
I’m trying to use the URL Access Scripting Standard Addition within Mac OS X. However, I’m finding that when I "tell application “URL Access Scripting” the script tries to launch the Classic version instead of using the Mac OS X version of URL Access Scripting. The only way I’ve been able to stop this was to delete the classic version of the OSAX from the System Folder. Is there a way to specifically target an OSAX for OS X instead of an OSAX for OS 9 when they have the same name? Or am I stuck with only being allowed to have one OSAX with a given name on my computer at a time?
Hi, i’m a little bit surprised here because i don’t think that when you’re scripting OS X you can use the scripting additions of OS 9 (or previous OS), but It might also because mine have to differents names.
URL Access Scripting isn’t an osax, but an app; so, you can target it by path (test this):
(path to scripting additions folder as text) & "URL Access Scripting.app"
tell application result
using terms from application "URL Access Scripting"
download "http://www.google.com/" to (choose file name)
end using terms from
end tell
I am having the same problem. But the previous solution does not work for me. The OS X URL Access Scripting is located in my /System/Library/Scripting Additions folder. This may be why the previous solution did not work. I’ve tried renameing the OS 9 addition, but when I compile the script it changes the name of the application in the script to match.
It seems like there should be a good way to deal with this sort of problem. Any help would be appreciated.
I feel much better having found others out there with the same problem–all the sudden, my script’s call to application “URL Access Scripting” no longer calls the native application, but starts “URL Access Scripting” in OS9 (with its long train of initiation stuff). JJ’s work-arround script is a great, however, I share Scott’s view that there has to be an easier way. Wouldn’t this problem occur for other like-named scripting addition applications of both OSX and OS9? Are there any other AppleScript pros out there who can shine some light on this problem?
UAS is not a scripting addition. It is an application. When you target an application in AppleScript, its creator code and full path is hardcoded at compile time.
Some folks reported some time ago that this syntax may work:
tell application "URL Access Scripting.app" --> AS may find OS X's version
--> whatever
end tell
If it doesn’t, just use the “target by path” workaround…
On the other hand, regarding real scripting additions, most opinions will tell you that you can use pre-X osaxen within a “tell block” targeting a pre-X application, as described in: http://macscripter.net/faq/comments.php?id=173_0_6_0_C
Thank you for your response, JJ. Your work around works great. Nevertheless, the problem that it solves makes me wonder about how AppleScript works. Why does it sometimes choose the UAS in one OS and not another–what is its criteria or how does it work? You mention that UAS is not an OSAX. I’ll take your word for this, but what is the difference between an OSAX and the kind of application UAS is? And why does Apple place UAS in the Scripting Additions folder if it’s not really a scripting addition?
Why does AS choose one app instead of the other? Well, I don’t know and it must not be an easy-to-fix issue (except for the near “dead” of OS 9 and duplicate applications).
I think that AS searches for, call, and store applications by “creator type”. As you may know, the creator type of applets is “aplt”. There are hundreds (or thousands) of applets in my disk. All they are carbon applications whose creator type is “aplt”.
So, this code:
tell application "Finder" to application file id "aplt" as alias
Returns only 1 applet. Seems that it returns the first applet found in my disk, alphabetically-hierarchically:
alias “julifos:Applications:4DWebSTAR:WebServer:cgi-bin:AppleEventExample.acgi”
julifos → my disk
Applications → first folder in disk
4DWebSTAR → first folder within “Applications”
… → the same
(wait! 4DWebSTAR??? I don’t need a web server! :evil: …)
Apple, traditionally, shipped several background applications which are thought only to be used with AppleScript: UAS, KeyChain Scripting, ColorSyncScripting… They are stored in the Scripting Additions folder… Well, I wouldn’t store them in this folder, but they must reside in some place and Apple thought this would be the better place…
You use these FBAs as any other application (Finder, Address Book…), using a “tell block”. There are other examples of background-scriptable applications, such as Kanzu’s Extra Suites or JB Le Stang’s MySQL Bridge.
Scripting additions, on the other hand, are chunks of compiled C/C++/whatever code and they must reside in the Scripting Additions folder or you won’t be able to use them. They are not applications and, consequently, are much quicker than regular applications, since they are libraries loaded in memory and operate on-the-fly.
Also, allways there was some methods to “embed” scripting additions within your own application, so you could use them if they were not installed in the user’s system. Actually, seems that applet-bundles in Panther can do it (I couldn’t still try this feature). Other apps in the past able to do this were Applet Binder or FaceSpan.
Thanks for your overview of how scripting additions (OSAX) differs from AppleScript applications (such as URL Access Scripting) and how AppleScript selects applications when you use a “tell” reference. Your information raise many more questions for me–a good thing–and I expect to get answers as I go. For now, your answer is plenty.
