Re: BUG? Constants to string
Re: BUG? Constants to string
- Subject: Re: BUG? Constants to string
- From: Christopher Nebel <email@hidden>
- Date: Fri, 4 Jan 2002 14:56:13 -0800
This a fundamental design flaw in how the enumeration-to-string coercion
works, and it's always been this way, but it's a little more obvious on
Mac OS X. AppleScript doesn't store the English name of enumerations
anywhere in a script; it only stores the raw code. Therefore, in order
to do the coercion successfully, it needs to have the application's
terminology loaded.
Now, AppleScript's terminology always gets loaded no matter where you're
running, so built-in enumerations like "kilograms" always work.
However, an application's terminology only gets loaded when compiling or
displaying (but not executing!) a script that talks to that
application. That's why it always works in Script Editor -- you just
compiled (or at least displayed) the script. When running as an applet,
though, you're just executing, so there's no terminology available, and
you get the raw code as a fallback.
Mac OS 9 will sometimes work in cases where Mac OS X won't: AppleScript
in Mac OS 9 shares terminology across the entire system, so if anyone
caused the terminology to be loaded, then it'll work anywhere. (E.g.:
boot up Mac OS 9. Run one of your applets -- you get the raw code.
Open the script in Script Editor and run it -- it works. Now run the
applet again -- it should work too.) Mac OS X, on the other hand,
doesn't share terminology between processes, so an applet will always
fail -- unless you take special steps.
You should be able to work around the problem by adding a dummy "run
script" command that talks to the appropriate application. For example,
this works fine on Mac OS X 10.1:
run script "tell application \"Finder\"
end"
tell application "Finder"
set p to owner privileges of file "Tukuul:HashDictionary.cp"
end tell
display dialog (p as string) --> "read write"
"run script" with a string will compile the string, and the "tell
Finder" will make it load the Finder's terminology into your process,
and now the coercion works.
--Chris Nebel
AppleScript Engineering
On Friday, January 4, 2002, at 01:30 PM, Paul Berkowitz wrote:
Can anyone explain what's going on here? This is in AS 1.8.1 on OS
10.1.2,
but it has existed previously, at least back to AS 1.6 in OS 10.1 and
9.1
(9.2.1?) in the second example.
If I run this script from Script Editor:
tell application "Finder"
set p to owner privileges of alias "OS X
HD:Users:berkowit:Desktop:Text
File.txt"
set txt to p as string
end tell
display dialog txt
--> read write
If I save it as an application, I get
--> <<constant ****rdwr>>
Similarly if I write it to a text file: "read write" when run in any
Script
Editor, <<constant ****rdwr>> when run from an application.
(According to Script Debugger's Dictionary, the raw code for read write
is
<<constant rdwr>> (just 4 characters).)
--------------
Similarly:
Entourage uses application constants for 'priority' property of tasks
and
messages. The possible constants for priority are lowest, low, normal,
high, highest. Let's take normal.
If I'm working in Script Editor , and run:
tell application "Microsoft Entourage"
set theTask to task 1
set p to theTask's priority
set txt to p as string
end tell
display dialog txt
--> normal
If I save the script as a compiled script and run it from Entourage's
own
script menu, I get
--> <<constant ****!nrm>>
If I save it as an application and run it there, I get
--> <<constant ****!nrm>>
If I write txt to a text file, it writes "normal" when run from both
Script
Editor and Entourage, but if I quit Entourage and relaunch it, then it
writes "<<constant ****!nrm>>". According to Script Debugger's
Dictionary,
the raw code for normal is <<constant !nrm>> (just 4 characters).
This is creating something of a muddle, and the need for extensive
workarounds. Does anyone know what this is about? Is this a bug or a
"feature" (some feature!) of AppleScript? And is it recent or ancient?