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