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: Sander Tekelenburg <email@hidden>
- Date: Wed, 8 Dec 2004 04:32:20 +0100
At 18:50 -0700 UTC, on 2004/12/07, Michelle Steiner wrote:
> On Dec 7, 2004, at 6:22 PM, Chris Espinosa wrote:
>
>> Some functions give you an object specifier, a "reference", to an
>> object in the app. And you may want to know what the containment chain
>> - the specific containment chain displayed in AppleScript - for that
>> object is, but the object may not have a property for its container.
>>
>> The object specifier knows the containment chain. That's why
>> AppleScript can display it the way it does, e.g. word 1 of paragraph 2
>> of document "foo". So AppleScript has, at runtime, its grubby little
>> mitts on all the information he wants.
>
> OK, that much I already knew.
>
>> There's just no built-in function to return, say, a list of objects
>> (e.g. {word 1 of paragraph 2 of document "foo", paragraph 2 of
>> document "foo", document "foo", application "TextEdit"})
>
> There's where I'm failing to understand. To get that list, either one
> would need to parse the object specifier--but since the object
> specifier is already known, why
Thin ice, I'm only 99% sure I understand. But without taking risks humanity
would never have invented jazz music or AppleScript, so here's my
contribution to that:
The way I understand the OP's question is: suppose you know the object, but
not its parent(s) - how then to get its object specifier (which would provide
that information).
You run into a baby in the street and decide you need to know its parents. We
know the information is embedded in the baby, we just can't access it. But
people with the necessary knowledge of DNA and access to the necessary tools
can. The OP wants to be able to do it himself. 'Ask' the baby and get a
useful result..
I think Chris' mention of a "list" is just a (probably sensible :)) example
of the form in which AS might conceivably return the object specifier. So the
point is not the list, thus the point is not how to parse an object specifier
and represent it as a list, but how to get the object specifier in the first
place when the only known information is the object itself.
If I understand correctly Chris tells us that AppleScript ('internally')
knows the object specifier for any object (I suppose that makes sense - an
object cannot exist in a vacuum, part of its existence is defined by its
parent object(s), like the baby), AppleScript just doesn't provide scripters
with a mechanism to request it. Paul's examples of individual applications
that do offer this function (giving access to it by offering it as an
accessible property of the object) show how it would work (for a scripter) in
practice.
It's a bit like not having the "info for" command while knowing that the info
is there, just not accessible to mere scripters. Gods could write a Scripting
Addition that would close that bridge, thusly providing us crawlers with a UI
to finally access what was already there.
What I cannot envision though is a practical application for this :) Exactly
when do you deal with an object whose parents you do not know but need to
know? Would anyone care to post an example please?
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
_______________________________________________
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