On 10 Apr 2014, at 11:26 am, 2551phil <email@hidden> wrote:
In short, user defined records have their key/value pairs
stored internally as lists (making it possible to coerce them) whereas existing records store the key names according to the four letter class code.
Sort of. Take a record that includes both kinds of value:
{someLabel:1, button returned:"OK", text returned:"Blah", otherLabel:"Boo"}
If you run that in Script Debugger with the result set to AEPrint, you get this:
{ 'bhit':'utxt'("OK"), 'ttxt':'utxt'("Blah"), 'usrf':[ 'utxt'("someLabel"), 1, 'utxt'("otherLabel"), 'utxt'("Boo") ] } You can probably get the idea from this. So 'bhit' is the code for button returned, 'ttxt' is the code for text returned, 'utxt' means text, and 'usrf' means user record fields. The square brackets designate a list, in this case of alternating labels and values.
Now suppose you run this:
tell application "Finder" to properties of item 1
You get something similar:
{ 'pnam':'utxt'("Extra"), 'pidx':5, 'dnam':'utxt'("Extra"), 'nmxt':'utxt'(""), 'hidx':'fals'("false"), ... }
But in this case, the codes have no meaning except in the context of the Finder's dictionary.
|