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: Paul Berkowitz <email@hidden>
- Date: Thu, 09 Dec 2004 09:42:27 -0800
That's good, Scott. The 'ref to' gets the object specifiers rather than
dereferencing (resolving) to values, and even lets you get individual
specifiers which have nothing to resolve to, without error, although it
always adds 'of application "Whatever"', naturally enough. This is indeed
close enough to what you were asking for in the first place. So if you parse
the text from the error message using " of " as delimiter, you can even do
this:
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"
set wordRef to run script "ref to word 12"
--> word 12 of application "TextEdit"
end tell
The last one there doesn't actually mean anything, but it does let you
isolate 'word 12' as an object if that's what you want.
--
Paul Berkowitz
> From: Scott Babcock <email@hidden>
> Date: Wed, 8 Dec 2004 17:20:20 -0800
> To: <email@hidden>
> Subject: RE: 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
>
_______________________________________________
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