Object paths?

[Ken Ray]

> I'm writing software that works well in Transcript, but I'm a 
> long way 
> from understanding it, and it is a long way from what I know.

Well, if it's any help, the context in which one works is generally the last
stack that was opened. The stack with the current "focus" is the
defaultStack, which can be changed explicitly if you want to work on another
stack without having to use a long path. For example, if you open a stack
called "Stack1" and then open another stack called "Stack2", "Stack2" is the
"current" (or default) stack. When you say:

  put "hello" into field "Greetings"

Rev looks for the a field called "Greetings" in stack Stack2. If you want to
put "hello" into the a similarly named field of stack Stack1, you can do it
either as:

  put "hello" into field "Greetings" of stack "Stack1"

OR

  set the defaultStack to stack "Stack1"
  put "hello" into field "Greetings"

Note that in the first example, I didn't have to say:

  field "Greetings" of card 1 of stack "Stack1"

Rev make certain assumptions about the object you're referring to, even if
it happens to be inside of a group that's inside of a group, etc. There is
also the concept of "this card", which refers to the currently displayed
card in the stack with the focus (the defaultStack), and "this stack", which
refers to the stack that contains "this card". For example, if my field
"Greetings" was in a group called "innerGroup" what was in a group called
"outerGroup", I could refer to it in any of the following ways (assuming the
context/defaultStack is the stack "Stack1" and the currently displayed card
is card #1):

  field "Greetings" of group "innerGroup" of group "outerGroup" of card 1 of
stack "Stack1"
  field "Greetings" of group "innerGroup" of group "outerGroup" of card 1
  field "Greetings" of group "innerGroup" of group "outerGroup"
  field "Greetings" of group "innerGroup"
  field "Greetings"

Additionally, I could have used:

  field "Greetings" of this card
  field "Greetings" of card 1 of this stack
  (etc.)

As long as there is no other field named "Greetings", Rev is smart enough to
understand what I mean even without a long reference. The basic rule of
thumb  is this:

  The shortest descriptor you can use is the one that will uniquely identify
the object you want.

So if I have two similarly named field in different groups, then I have to
*at least* refer to the object name and its group name. So using my example,
suppose there was a field "Greetings" in a group called "Group1" and another
field called "Greetings" in a group called "Group2", both of which sit on
card 1 of stack "Stack1". The shortest descriptors I can use to address the
two fields are:

  field "Greetings" of group "Group1"
  field "Greetings" of group "Group2"

If I just used:

  field "Greetings"

Rev would select the first field that it found (I believe it would use layer
order) and use that one. 

Now the question is one of context and "where are we"... Compare:

Script of card 1 of stack "Stack1"
----------------------------------
on DoIt_1
  put "Hello" into field "Greetings"
end DoIt_1

Script of stack "myLibrary"  -- put into use with "start using" as a
libraryStack
---------------------------
on DoIt_2
  put "Hello" into field "Greetings"
end DoIt_2

If I have a button on card 1 of stack "Stack1" that executes "DoIt_1", Rev
will look for a field called "Greetings" on the current card.
If I have a button on card 1 of stack "Stack1" that executes "DoIt_2", Rev
will *also* look for a field called "Greetings" on the current card... it
will NOT try to find the field "Greetings" on the stack "myLibrary". Why?
Because the script is being executed in the context of "the target" - which
in this case is the button. 

Now if I said:

  send "DoIt_2" to stack "myLibrary"

The "target" in this case is the stack "myLibrary", and so Rev will look for
a field called "Greetings" on the "myLibrary" stack.

Rev is usually pretty smart about evaluating the context of its operations;
if you feel inclined, there's nothing wrong about "nudging" Rev in the
direction you'd like it to go, even if it would probably get there itself.
For example, this handler in stack "myLibrary":

on DoIt_2
  set the defaultStack to the topStack
  put "Hello" into field "Greetings"
end DoIt_2

... causes no harm at all, and tells Rev to focus its attention on the
topStack (which it probably was doing already) such that it should look for
the field "Greetings" in the topstack and not in the library. Note that
doing this would also cause the "send" command I mentioned above to work
equally as well, since it resets the "pointer" (if you will) to the topStack
in both cases.

So you can see why I generally never need to refer to an object by its long
path...

HTH,

Ken Ray
Sons of Thunder Software
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/