Re: interesting discovery (trying to get record labels as strings)
Re: interesting discovery (trying to get record labels as strings)
- Subject: Re: interesting discovery (trying to get record labels as strings)
- From: John W Baxter <email@hidden>
- Date: Sun, 2 Dec 2001 16:31:51 -0800
At 13:13 -0700 12/2/2001, Michelle Steiner wrote:
>
On 12/2/01 11:23 AM, has <email@hidden> wrote:
>
>
>This just throws an error, as you'd expect. However, try this:
>
>
>
> {{a:1}} as string
>
>
>
>and the results are _much_ more interesting. Try it and see. (Though if it
>
>doesn't generate a lot of seemingly nonsensey stuff, let me know what
>
>version of AS you're on [I'm on 1.3.7] as there's not much point pursuing
>
>this if it won't work everywhere.)
>
>
with AS 1.6, using {{hello:65}} as string I get
>
>
--> "usrflist\"TEXThellolongA"
>
>
The A at the end corresponds to ascii 65.
>
>
Even more interestingly: {{hello:"goodbye"}} as string
>
>
--> "usrflist&TEXThelloTEXTgoodbye"
>
>
And then there's this: {{hello:{65, 66}}} as string
>
>
--> "usrflist>TEXThellolist
>
longAlongB"
>
>
Or this: {{hello:{"one", "two"}}} as string
>
>
--> "usrflist>TEXThellolist
>
TEXToneTEXTtwo"
>
AppleScript puts items into a record in two ways (not helpfully, although I
think helpfulness was the original intent). It is working within the
constraints of the Apple Event Manager record type, which is a list keyed
by the usual four-byte codes ("oapp" and all the others we toss around
here), with a value associated with each key which can be pretty much
anything which can be represented as an AppleScript object.
Item keys which AppleScript "knows" as keywords use the known four byte code.
Other item keys are stuffed into the item with the key "usrf" ("user
fields", I think). The value of the "usrf" item is an Apple Event Manager
list (at least when the record is packed up and shipped in an Apple
event...it could be an AppleScript internal list internally). The list
alternates key values (as type TEXT, the name one gives the item in the
record..."hello" in the closest example above) with values (as whatever
they are (the list which contains two items of TEXT in the same example)).
It is trivial to build these things so that AppleScript can understand
them. It's also trivial to break them apart. Unfortunately, it's not
trivial to do either thing arbitrarily in AppleScript, which has only the
published ways to access items in records.
I had a reasonably favorable response a few months ago when I suggested to
Chris Nebel that
1. AppleScript forget about special casing record keys it knows about, for
making new records (it obviously has to deal with existing ones); and
2. provide access to the remaining one thing in a record, the "usrf" list.
But...there is no reason to expect to see the features any time soon, if at
all.
You can partly achieve #1 today... the name |application| on a record item
places that record into the "usrf" list, not up in the known keywords part
of the underlying record. But then you're stuck remembering that the two |
characters are part of the name. |application| is just an example; I could
just as well have said |run|.
Given 2, one could learn what items are in a record, could build an
arbitrary record on the fly (rather than at compile time), etc.
Someone could write an OSAX which hands over the "usrf" list from a record,
probably with the non-usrf items stuck onto the end of the list, or stuffs
a list...after checking for suitability...into the "usrf" field of a new
record and hands back the record. Aside from the OSAX boilerplate, it
would be about one screen of code to hold both functions. Given that OSAX,
everything else I've recently seen talked about could be done in
AppleScript code, with the following cavaets:
a. AppleScript would tend to move items named with known keywords out of
the "usrf" list if it had any reason to rebuild the list (I ran into this
in the mid-1990s when playing with building arbitrary AppleScript records
in Frontier and handing them to AppleScript).
b. And if a happens, AppleScript will change the case of the item name to
match what it "knows" (or it would do that in the mid-1990s).
--John
--
John Baxter email@hidden Port Ludlow, WA, USA