Getting the labels of a record (revisited): Part 1 of 2
Getting the labels of a record (revisited): Part 1 of 2
- Subject: Getting the labels of a record (revisited): Part 1 of 2
- From: Kai <email@hidden>
- Date: Sun, 11 May 2003 23:03:14 +0100
on Wed, 16 Apr 2003 10:58:02 -0700, Jon Pugh <email@hidden>
wrote:
>
At 2:00 PM +0100 4/16/03, John Delacour wrote:
>
>At 12:42 pm +0200 16/4/03, Emmanuel wrote:
>
>
>
>>Good morning, Kai!
>
>>
>
>>------------------------------
>
>>set r to {name:"mice elf"}
>
>>------------------------------
>
>>
>
>>getkeys from r
>
>> --> {}
>
>>
>
>>boo-hoo ...
>
>
>
>Same with mine. This 'name' thing is getting beyond a joke. It's a worse
script-breaker than 'file' it seems.
>
>
You realize the issue, don't you?
>
>
Keys which are in the aeut or an aete are stored as the 4 character constant,
while undefined terms are stored as strings in the usrf record. Your
technique was to parse the usrf record, which doesn't contain things like
name, file, parent and other AppleScript terms.
>
>
I think Paul's idea is more sensible, but I'm not holding my breath. ;)
Due to an absence, I was unable to participate in the conclusion of this
thread. However, as most solutions to date seem to have involved
considerable compromise (and since I imagine that - by now - the faces of
those not following Jon's example might have turned a rather nasty shade of
purple), the subject may still still be worth a revisit.
As Jon pointed out, part of the problem appears to stem from the way in
which the raw data is stored. It occurred to me that one way forward might
be to try and analyse the data structure itself. Theoretically, it should be
possible to come up with a script that sifts methodically through the raw
data to produce a definitive list of keys/labels. To do this, such a script
would need to search outside the usrf records, locate and identify any
four-character constants (converting them back to their corresponding
keywords along the way) - and then collect undefined terms from within the
usrf records. Obviously, it must also distinguish keys/labels from standard
entries.
I've cobbled together a routine that attempts to achieve just that. From
tests so far (OS 9.1 / AS 1.8.3 and OS 10.2.5 / AS 1.9), it seems to do the
job, also taking account of slight differences in data structure returned
from the different test environments. (I'm not sure precisely when this
structural change might have been introduced.)
Granted, the script's not as brief (in terms of length or performance) as
I'd prefer - although, with a little judicious hard-wiring, there's still
some room for optimism... - sorry, optimisation. On the other hand, the
technique may ultimately offer more reliability than tid-based methods:
--============================
to getKeys from r with dupes
tell r's class to if it is not record then error "Can't get keys from "
& it & "."
local dupes
set r to {r} as string
script s
property a : (ASCII character 199) & "class "
property z : ASCII character 200
property o : ASCII character 0
property d : r
property k : {}
property m : 0 - 8
on val(x)
set {t, v} to {d's text (x - 3) thru x, 0}
repeat with n from 1 to 4
set c to t's item n
if c is not o then set v to v + (ASCII number c) * (256 ^ (4 - n))
end repeat
v
end val
on nxt(n)
set m to m + n
if d's text (m + 1) thru (m + 4) is "reco" then return rec()
set m to m + 8
tell val(m) to set m to m + it + it mod 2
end nxt
on usr()
set m to m + 20
repeat val(m - 4) div 2 times
set m to m + 8
tell val(m) to set {q, m} to {d's text (m + 1) thru (m + it), m + it +
it mod 2}
if dupes or q is not in k then set k's end to q
if d's text (m + 1) thru (m + 4) is "list" then
lst()
else
nxt(0)
end if
end repeat
end usr
on lst()
set m to m + 16
repeat val(m - 4) times
nxt(0)
end repeat
end lst
on rec()
set m to m + 16
repeat val(m - 4) times
set n to d's text (m + 1) thru (m + 4)
if n is "usrf" then
usr()
else
tell (run script a & n & z) as string to if dupes or it is not in k then
set k's end to it
nxt(4)
end if
end repeat
end rec
if d starts with "d" then set m to 8
tell rec() to k
end script
run s
end getKeys
--============================
-------------------------------------------------------
(Any wrapped lines abutting the left edge of the window
should be reconnected to the end of the previous line)
-------------------------------------------------------
-----------------
-- test record --
-----------------
set r to {subject:"Re: Getting the labels of a record", date:date "6/6",
|time sent|:"14:36:25 pm", list:{list:{number:1576, string:string}},
alias:{path:{name:{disk:{folder:{file:{item:false}}}}}}, file:"Macintosh
HD:Desktop Folder:test", |initial values|:{list:{1, 2, 3, 4}, |final
average|:10 / 4}}
-------------------------
-- test calls & results --
-------------------------
getKeys from r with dupes
--> {"date", "list", "list", "number", "string", "alias", "path",
"name", "disk", "folder", "file", "item", "file", "subject", "time sent",
"initial values", "list", "final average"}
getKeys from r without dupes
--> {"date", "list", "number", "string", "alias", "path", "name",
"disk", "folder", "file", "item", "subject", "time sent", "initial values",
"final average"}
--============================
Due to the way in which the raw data of records is structured, the resulting
key values are not necessarily returned in the order entered. In addition,
as I mentioned earlier, this isn't a particularly speedy solution - so it
might not cut the mustard for time-critical scripts that need to grab keys
on the fly.
In view of this, I also tried a variation on the error/tids approach.
================================
(Please see part 2 of this message for the alternative method.)
--
Kai
_______________________________________________
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.