Script Only Stack Architecture

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

 > ergo: merely opening a script-only stack that is applied as a
 > behavior to a control (not global in scope) does *not* place
 > into the msg path.

Respectfully, your recipe would be easier to follow without the steps 
unrelated to the actions we're exploring (making folders and such - the 
folder locations are unrelated to the problem).

Remember guideline #2 in my earlier post:

   2. When using behaviors, the object containing the behavior script
      must be in memory when anything relying on it is brought into
      memory.
<http://lists.runrev.com/pipermail/use-livecode/2016-March/225274.html>

If I'm following your recipe correctly, the field object that uses the 
behavior is in a stack that opens and then loads the stack used to 
define the behavior.

This means that at the moment the field object is unpacked for use it 
contains a reference to a behavior object not yet in memory.

The engine (in its current form; we can expect this to be improved later 
as time permits) will only attempt to resolve a behavior once, when the 
object dependent on the behavior is brought into memory.

Even if you later open a stack containing the behavior script, by that 
time it's too late.  The object depending on it has already been 
unpacked, the behavior reference already attempted, and having failed it 
will not be retried as other stacks are later opened.

For the moment let's forget that in your case the stack file used as a 
behavior object is a script-only stack.  The storage format doesn't 
affect anything at runtime, and may be distracting here.  Let's just 
focus on the load order:


SIMPLIFIED RECIPE
-----------------
Stack "MyTestStack" has a field, which is assigned stack 
"MyBehaviorStack" as its behavior property.

Stack "MyBehaviorStack" is a separate stack file.


POSSIBLE SOLUTIONS
------------------
Options for correct behavior esolution when "MyTestStack" is loaded include:


a) Open "MyBehaviorStack" first.
    -----------------------------
    In an application this may mean introducing one more stack, which
    we could call "MyBootStack", which first opens "MyBehaviorStack"
    and then opens "MyTestStack".


b) Load "MyBehaviorStack" into memory without opening it.
    ------------------------------------------------------
    This can be done by accessing a property of "MyBehaviorStack",
    such as the stack's name.  This still requires "MyBootStack"
    to make sure that "MyBehaviorStack" is in memory before
    "MyTestStack" is opened, but has the minor convenience of
    not being visible to the user and triggers no opening messages.


c) Include "MyBehaviorStack" in the stackFiles prop of "MyTestStack".
    -----------------------------------------------------------------
    Any stack files specified in the stackFiles property of a stack
    are loaded into memory at the same time the stack containing that
    list is loaded.  In terms of boot sequence it's functionally
    similar to having those separate stack files as substacks, but
    with the advantage of keeping them separate.


a) and b) conform to Guideline #2 above in an obvious way, explicitly 
putting "MyBehaviorStack" into memory before "MyTestStack" will be 
opened to need it.

c) works because stack files listed in the stackFiles property are all 
loaded with the stack listing them, before behavior resolution takes place.


This seems harder than it is in part because you're super smart and are 
just thinking too hard. :)

Relax.  Put script-only stuff out of your mind, and just think about the 
load order.

Behaviors are among the most powerful things ever introduced in the 
xTalk family of languages.  I waited literally 20 years for them, since 
Allegiant first accepted my proposal for parentScripts but then went 
belly-up before they could implement it.  Well worth even that wait: 
they greatly simplify so many aspects of building complex systems, and 
simple systems become simpler.

The load order rule (Guideline #2 above) in LC is a bit funkier than 
we'd hope for, but even that's not hard to accommodate once we 
understand it.

Pick a, b, or c, to handle the load order, and the world is your oyster.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com