Re: Picking data from a record
Re: Picking data from a record
- Subject: Re: Picking data from a record
- From: has <email@hidden>
- Date: Sun, 26 Sep 2004 11:29:08 +0100
Paul Berkowitz wrote:
> set finalResult to run script testThis & " of (get parent's testRecord)"
Well, this is very odd:
It runs just fine in Script Debugger 3.0.8 without the 'get'.
In Smile 2.5.9, it errors "Can't get h of testRecord' without the 'get', but
runs fine with the 'get'.
In Script Editor 2.0, it errors "AppleScript Error:
NSCannotCreateScriptCommandError" both with and without the 'get'.
Which is absurd. A standard addition command (run script) should not depend
on which editor is running it.
I'd be surprised that works at all. The 'run script' osax compiles
script objects with their parent properties set to the root
AppleScript object. It may be that some editors implement
[un]documented 'run script' commands with different behaviour to the
osax version. An application-defined 'run script' command might
compile the source code into a script object and set its parent
property to the script that called the command before running it.
That would make the calling script's top-level globals, properties
and handlers available to the newly compiled script, though I'm not
sure this is would be a good idea in practice.
Anyhow, it's a pretty dicey way to do this sort of stuff. A slightly
better approach would be to pass the parent-to-be into the 'run
script' command as a parameter to its 'run' call:
property x : 42
run script "
on run {parentObj}
script Foo
property parent : parentObj
display dialog my x as string --> 42
set my x to 13
display dialog my x as string --> 13
end script
run Foo
end run
" with parameters {me}
display dialog my x as string --> 42
Note that script object Foo actually takes a _copy_ of the main
script as its parent, not the original; data being packed into an
Apple event's parameters is copied as part of this process. The best
solution is to compile and return a script object that contains a
constructor, makeObj, that can be used to create the Foo script
object within the main context where its parent property can be set
to the original script rather than a copy:
property x : 42
set scpt to makeObj(me) of (run script "
script
on makeObj(parentObj)
script Foo
property parent : parentObj
display dialog my x as string --> 42
set my x to 13
display dialog my x as string --> 13
end script
return Foo
end makeObj
end script
")
run scpt
display dialog my x as string --> 13
Looks a bit mind-bending to look at if you're not used to dealing
with AppleScript's object system in depth, but actually quite simple
and elegant [1].
...
Anyway, getting back to situations where using something like Types'
Dictionary object isn't an option (e.g. when working with records
produced by a third-party) and you have no choice but manipulating
records dynamically, I wrote a library a while back [2] that
implements a relatively safe [3] solution:
http://freespace.virgin.net/hamish.sanderson/Record.sit
Lets you do stuff like:
_Record's getVal({foo:1, bar:3, baz:5}, "bar") --> 3
_Record's recToList({foo:1, bar:3, baz:5}) --> {{"foo", 1},
{"bar", 3}, {"baz", 5}}
It's an 0.1.0 release that still needs work as it only allows you to
get and set properties that are AS identifiers (e.g. x, |foo bar|,
|class|); it doesn't currently let you reference properties that are
AS keywords (e.g. class, name). Adding additional getValByKeyword and
setValByKeyword handlers that don't automatically put pipes around
key strings should be easy enough in itself - the main problem is
that this opens up a big nasty security hole whereby malicious code
could be included in the propertyName string to be compiled and
executed; and I got bored before figuring out a solution to this [4].
But it's there for anyone that wants to use it/finish it.
BTW, another option for manipulating records is LNS's RecordTools osax:
http://www.latenightsw.com/freeware/RecordTools/index.html
HTH
has
[1] For a program that generates and compiles source code on the fly,
anyway - a noxious process in anything except Lisp.
[2] Sent it to AppleMods too, but it doesn't appear to be posted
there so have slung a copy on my own site fyi.
[3] i.e. It's still a total hack that might well go wrong in a
hundred horrible ways, but at least attempts to avoid the most
obvious problems.
[4] ... since I'm mostly using Python these days, and Python has an
excellent built-in 'dict' type so there's absolutely no need for such
nonsense there.
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden