Script Only Stack Architecture

Fri Apr 1 10:34:31 EDT 2016

> It's a pain to open the object inspector and copy the behavior reference
> then use the message box to to "open script of…"

This is no longer necessary in the latest DPs of 8.0 - the behavior
property in the property inspector has an 'edit script' button.

On Fri, Apr 1, 2016 at 3:21 PM Peter M. Brigham <pmbrig at gmail.com> wrote:

> 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
>
>
> _______________________________________________
> 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
>