Peter Haworth wrote:
Thanks for the explanation Richard. This stuff isn't made any easier
by the fact that there are multiple names available for the same thing
- behavior=parentScript apparently.
You can safely ignore "parentScript". That was the name that I used
when I first proposed this feature many years ago, having picked it up
from meetings with the SuperCard team years earlier when they were
considering it.
Rev adopted it for an early beta distribution, but by Beta 2 they had
come up with "behavior" instead, and noted in the ParentScript Notes
that "parentScript" is deprecated; while it's currently accepted as a
synonym for behavior to help a few people who started building big
projects with that early beta, it won't live forever.
Getting back to Mark's answer and the use of stack files, I see two
separate places where additional stack files can be specified - the
stackFiles property of the main Stack (or the equivalent pane in the
main stack inspector), and the Stacks pane of the Standalone
Application Settings which gives rise to the question, what is the
relationship between these two settings? Does one override the other?
Is stackFiles operative for the development environment only and the
standalone setting for standalone applications only?
Two different things:
The "Stacks" pane in the SB is used for copying separate stack files
into the file that will become the standalone.
The stackfiles property of a stack is a list which allows the engine to
easily locate stacks which aren't in the stackfile so that you can still
refer to them by just their short name in your scripts.
For example, if you have a stack named "Behaviors" in a stack file named
"Behaviors.rev" in a folder named "Components" which is in the same
folder as your stack file or standalone, you can set the stackfile's
property of your stack to:
Behaviors,Components/Behaviors.rev
...and the engine will then know exactly where to find the stack
whenever your scripts refer to a stack named "Behaviors".
--
Richard Gaskin
Fourth World
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
