RE: Unwinding the containment hierarchy of a reference
RE: Unwinding the containment hierarchy of a reference
- Subject: RE: Unwinding the containment hierarchy of a reference
- From: "Scott Babcock" <email@hidden>
- Date: Wed, 8 Dec 2004 17:20:20 -0800
- Thread-topic: Unwinding the containment hierarchy of a reference
In order to reconstitute a reference from a string, you need the
complete hierarchy from the deepest object clear up to the application:
set appRef to run script "application \"TextEdit\""
--> application "TextEdit"
tell appRef
set docRef to run script "ref to document 2"
--> document 2 of application "TextEdit"
set wordRef to run script "ref to word 12 of document 2"
--> word 12 of document 2 of application "TextEdit"
end tell
-- must replace fake guillemets with the real thing
set obj1 to "<<class wTxR>>" -- text range (text object)
set obj2 to "paragraph 1"
set obj3 to "document \"Foo\""
set appStr to "application \"Microsoft Word\""
set appRef to run script appStr
--> application "Microsoft Word"
tell appRef
run script "ref to " & obj1 & " of " & obj2 & " of " & obj3
--> text object of paragraph 1 of document "Foo" of application
"Microsoft Word"
end tell
The phrase "ref to" ensures that you don't get bitten by implicit
dereferencing. Also, if you don't use the 'tell' block, the references
you get may not include the application object.
This technique works even if your object strings contain raw specifiers
for application-specific classes - (e.g. - <<class wTxR>>).
-----Original Message-----
Date: Wed, 08 Dec 2004 15:31:22 -0800
From: Paul Berkowitz <email@hidden>
Subject: Re: Unwinding the containment hierarchy of a reference
To: AppleScript-Users <email@hidden>
Message-ID: <BDDCCECA.802AA¾email@hidden>
Content-Type: text/plain; charset="US-ASCII"
On 12/8/04 2:53 PM, "Michael Terry" <email@hidden> wrote:
>> You can't do a 'run script' on the separate elements since some don't
>> resolve as incomplete ("word 12") and those that do (elements of the
>> application) tack on 'of application "TextEdit". ("TextEdit" itself
results
>> in 'current application'.)
>>
>> But if strings are good enough, I guess you've got your bits.
>>
>> What purpose does this serve? Something along the lines of what Chris
is
>> describing? Or maybe a way of pinpointing errors without running a
script in
>> a script editor?
>
> When I suggested using the error text to Scott, I didn't lay it all
out for
> him, but he understood immediately that he would use 'run script' to
> reconstruct the object references. If you've got an object specifier,
and you
> can get it as a string, then you can take whatever pains you want to
parse it
> and turn pieces of it back into valid object specifiers using 'run
script'.
But only valid specifiers. And then you get the value, not the object
specifier, if there is a value. Try it, in a TextEdit tell block.
tell application "TextEdit"
run script "word 12"
--> ERROR: NSCannotCreateScriptCommandError
run script "word 12 of document 2"
--> "Dept." -- the value, not the object specifiers
run script ("word 12 of document 2 of application \"TextEdit\"")
--> "Dept." -- the value, not the object specifiers
run script "document 2"
--> document 2 of application "TextEdit" -- at last!
end tell
run script doesn't help much in most cases. Only for elements of the
application, it seems. Properties need the full chain of object
specifiers
not to error, which is where we started out, and then they resolve to
their
value. If their value is not an application object but rather text,
number,
date, etc. - AppleScript returns this value, not the application object
+
property specifiers. I don't think this is what Scott wanted. The
strings
are better, for humans at least.
>If
> you wanted, you could create a list of the parent objects.
Top-level application objects, yes.
> If you wanted to
> create a more universally useful handler, and have it work with
multiple
> applications, that'd require some extra work. For example, some
objects might
> be specified with a name reference, so could contain the " of "
string.
I don't follow here.
--
Paul Berkowitz
_______________________________________________
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