Re: Results differ in editor and applet
Re: Results differ in editor and applet
- Subject: Re: Results differ in editor and applet
- From: Chris Espinosa <email@hidden>
- Date: Thu, 26 Feb 2004 13:03:28 -0800
On Feb 26, 2004, at 12:08 PM, Mr Tea wrote:
>
This from Paul Berkowitz - dated 26/2/04 6.26 pm:
>
>
> On 2/26/04 9:17 AM, "Mr Tea" <email@hidden> wrote:
>
>
>
>> When I run this in a script editor...
>
>>
>
>> tell application "iTunes"
>
>> set c to class of current track as string
>
>> my dlog(c)
>
>> end tell
>
>>
>
>> on dlog(c)
>
>> display dialog c
>
>> end dlog
>
>>
>
>> ... the dialog displayed is "audio CD track"
>
>>
>
>> But, when the same script is run as an applet, it displays "<<class
>
>> cCDT>>"
>
>>
>
>> Why the difference? Why!?
>
>
>
> The "Englishy" keywords aren't preserved outside their own context
>
> (application tell block). The same thing happens when you export
>
> application
>
> constants (e.g. 'highest as string' in Entourage, referring to
>
> priority of a
>
> task or message) to a text file. I think that script editors preserve
>
> the
>
> context somehow while you're in them - I'm not clear on this.
>
>
>
> To make the app's dictionary accessible to the script, include this
>
> near the
>
> top of the script, before you call the application:
>
>
>
> run script "tell application \"iTunes\"
>
> end tell"
>
>
This works (thanks, Paul), but I don't really understand why. Is this
>
another piece of undocumented AS esoterica?
>
>
I thought I had covered the problem of Englishy key words not being
>
'preserved outside their own context' by converting the key words
>
'audio CD
>
track' to the string '"audio CD track"'.
>
>
If an applet tells iTunes to get the class of the current document and
>
convert it to a string, surely that command is happening inside the
>
iTunes
>
application tell block in the applet, just as it's happening inside
>
the same
>
tell block when run from Script Editor, Script Debugger, or Smile, and
>
the
>
string that gets exported to the handler should be the same in either
>
case...
>
>
Maybe one of the AS insiders here could explain it?
Because the AppleScript runtime (the part that runs the scripts)
doesn't want to invest the extra time in loading all the information
that's needed in order to compile and syntax-check scripts if it's not
necessary. The textual representation of event, class, and parameter
names is needed only when you compile a script (or when an error is
being reported), so it's not loaded when you're just running scripts.
Of course, because the Script Editor is compiling scripts, it's loaded
when you're running the script in the Script Editor.
I's probably better to handle the above by comparing c against known
classes. Here's an example:
set c to class of "Hello" // or 2 or False, for this example
set l to {{integer, "integer"}, {string, "string"}, {boolean,
"Boolean"}} // use iTunes track classes here
repeat with i in l
if item 1 of i is c then return item 2 of i
end repeat
Chris
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.