Script Only Stack Architecture

Fri Apr 1 10:21:03 EDT 2016

Re this discussion on behaviors and chained behaviors, would there be any use for a new engine-based property like "the effective scripts of <objRef>" that would return the script of the object and all the behavior scripts in its chain? Perhaps as an array, with the control references as keys? I don't use behaviors much, but I sometimes run into the problem of needing to access the behavior script of an object, when I've forgotten which behavior button I used. It's a pain to open the object inspector and copy the behavior reference then use the message box to to "open script of…" 

But as I say, I don't use behaviors as much as I should, perhaps. Those who use them a lot will be better able to chime in on how useful or superfluous the idea might be.

-- Peter

Peter M. Brigham
pmbrig at gmail.com
http://home.comcast.net/~pmbrig

On Mar 31, 2016, at 3:43 PM, Richard Gaskin wrote:

> 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
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode