> 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 <pmb...@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 > 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 > _______________________________________________ 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
