Thanks for the comments. Very interesting. And I guess the big advantage of behaviors over a library is the scope issue.
I’ll put this info into my toolchest. Best, Bill > On Mar 31, 2016, at 3:33 PM, Ali Lloyd <ali.ll...@livecode.com> wrote: > > Or more accurately > on preOpenStack > local tBehaviorLongID > put the long id of stack "<path to MyBehaviorStack>" into tBehaviorLongID > set the behavior of field "FieldWithBehavior" of me to tBehaviorLongID > end preOpenStack > > On Thu, Mar 31, 2016 at 11:31 PM Ali Lloyd <ali.ll...@livecode.com> wrote: > >> My solution to this: >> >> Stack "MyTestStack" has a field, which is assigned stack >> "MyBehaviorStack" as its behavior property. >> >> Stack "MyBehaviorStack" is a separate stack file. >> >> would be to also include the behavior *setting* in the preOpenStack >> handler of "MyTestStack". >> >> on preOpenStack >> set the behavior of field "FieldWithBehavior" of me to <path to >> MyBehaviorStack> >> end preOpenStack >> >> This is the model used repeatedly for such things in the IDE. >> >> On Thu, Mar 31, 2016 at 10:10 PM William Prothero <proth...@earthednet.org> >> wrote: >> >>> Richard: >>> Ok, for the sake of argument (and my learning), compare that to: >>> >>> 1. Make new stack and call it “Alt Behavior Playground” >>> >>> 2. Make a new button and enter the script: >>> on mouseDown >>> >>> put the long ID of the target into theTarg >>> >>> doABehavior theTarg >>> >>> end mouseDown >>> >>> 3. Make a substack and call it “myBehaviorLib” —just for the heck of it. >>> Put the following script in it: >>> >>> on doABehavior tCtl >>> >>> doTheGrab tCtl >>> >>> end doABehavior >>> >>> >>> on doTheGrab tCtl >>> >>> grab tCtl >>> >>> end doTheGrab >>> >>> 4. Better do: start using stack “myBehaviorLib” >>> >>> Run it and drag the button you made. This will work in all stacks with >>> the on mouseDown script in it. >>> >>> So, the “myBehaviorLib” substack could be simply a script only stack that >>> contains some reasonable number of separate behavior type scripts, and once >>> the “start using” is invoked, say on a preopenStack script, all common code >>> for button behaviors becomes a single code element. Inheritance, like >>> adding new behavior is just adding another script to the “on doABehavior” >>> handler in the “myBehaviorLib” stack. What you don’t get is the ability to >>> have the same name for a bunch of different behaviors, but …… perhaps it’s >>> easier to keep track of handler names that are different anyway. >>> >>> Somehow, this seems more direct to me. It also avoids the need for a >>> preloader stack the opens a bunch of small files that are behaviors. >>> >>> What do you think? >>> Bill >>> >>> >>> >>>> On Mar 31, 2016, at 9:52 AM, Richard Gaskin <ambassa...@fourthworld.com> >>> wrote: >>>> >>>> William Prothero wrote: >>>> >>>>> Reading this kinda makes my head spin. Now I’m thinking it is going >>>>> to be a heck of a lot more robust for my situation, as a single >>>>> developer, to not use behaviors at all, but to have a single >>>>> (possibly script only) substack that holds all of the handlers that I >>>>> would normally use as behaviors, and just put a call to that handler >>>>> in each button. I can use “the target” or “me” as a passed variable >>>>> to make the action specific to a particular control. >>>>> >>>>> This approach seems a lot less prone to idiosyncrasies and more >>>>> easily transportable to other apps, to me. It also means that all of >>>>> my “behavior type scripts” would sit in a single script-only stack, >>>>> which would make it a lot more convenient to access and edit than a >>>>> bunch of small script only stacks sitting in my project browser. >>>>> >>>>> Am I wrong. misguided, foolish, or brilliant? >>>> >>>> Behaviors are very powerful for all sorts of things, whether you work >>> alone or in a team of twenty. >>>> >>>> The biggest benefit for teamwork comes from the very separate question >>> of whether to use script-only stacks to define behaviors. Script-only >>> stacks are an ideal solution for Github-based workflows, but have minimal >>> value (some, but not as much) for anyone not dependent on a version control >>> system designed for other languages. >>>> >>>> Ditch script-only stacks for now and continue to explore behaviors. >>> You'll thank me. You'll want to buy me lunch next time I'm in Santa >>> Barbara. I'll accept. Behaviors will change everything, very powerfully, >>> the more you explore and use them. >>>> >>>> Once we step away from the very separate issue of script-only stacks, >>> we have really only two guidelines for using behaviors effectively: >>>> >>>> - A behavior definition can be any button or stack. >>>> >>>> - When using behaviors, the object containing the behavior script >>>> must be in memory when anything relying on it is brought into >>>> memory. >>>> >>>> That's it. >>>> >>>> When exploring a new feature I like to make a simple stack I can use as >>> a playground to poke around and experiment without mucking up anything >>> important I'm working on. >>>> >>>> Here's a quick tutorial that may get you hooked on the power of >>> behaviors: >>>> >>>> 1. Make a new stack titled "Behavior Playground" >>>> >>>> 2. Add a button named "MyClass" >>>> >>>> 3. Set the script of that button to: >>>> >>>> on mouseUp >>>> answer the name of me >>>> end mouseUp >>>> >>>> There - you've just created a behavior, defining an action for what >>> will be an entire class of custom button objects: >>>> >>>> 4. Make a new button named "A" >>>> >>>> 5. In the Message Box run: >>>> >>>> set the behavior of btn "A" to the long id of btn "MyClass" >>>> >>>> 6. Make two copies of btn "A", naming them "B" and "C" respectively. >>>> >>>> 7. Click any of them. >>>> >>>> What you'll see is that each of them uses the script of button >>> "MyClass" as if it's their own, bringing up an answer dialog showing the >>> unique name of each. >>>> >>>> At this point your mind is already thinking of a dozen times in recent >>> projects where you have several objects you wanted to work the same without >>> affecting any other scripts. We could leave it here and you'd be off >>> writing behaviors very productively right now. >>>> >>>> But we're going to take this one step further - we'll create a >>> superclass: >>>> >>>> 8. Make a new button named "MySuperClass" >>>> >>>> 9. Set this script of that button to: >>>> >>>> on mouseDown >>>> grab me >>>> end mouseDown >>>> >>>> 10. In the Message Box run: >>>> >>>> set the behavior of btn "MyClass" to the long id of btn "MySuperClass" >>>> >>>> 11. Drag any of the "A", "B", or "C" buttons. >>>> >>>> In just 11 steps, each taking only a few seconds, you've just created a >>> rich hierarchy of custom messaging: >>>> >>>> "A" "B" "C" >>>> \ | / >>>> \ | / >>>> MyClass >>>> | >>>> | >>>> MySuperClass >>>> >>>> >>>> If you wanted the drag behavior used for an entirely different set of >>> objects that do something else on mouseUp, you could make another button >>> named "MyOtherClass" and extend your scope of custom controls even further: >>>> >>>> "A" "B" "C" "D" "E" "F" >>>> \ | / \ | / >>>> \ | / \ | / >>>> MyClass MyOtherClass >>>> \ / >>>> \ / >>>> MySuperClass >>>> >>>> Behaviors can be chained as deeply as you like, allowing for very rich >>> class hierarchies. >>>> >>>> This will get you started. And it only takes a few minutes to explore. >>>> >>>> >>>> ------ EXTRA CREDIT ------- >>>> >>>> After you feel comfortable with this, an extra credit exercise might be >>> explore overriding and overloading. >>>> >>>> Overriding is blocking an action defined in a parent by using a handler >>> of the same name in a child. >>>> >>>> For example, if you decided button "C" was different from the others >>> and should reports its long ID rather than its name, you could write a >>> script in it with: >>>> >>>> on mouseUp >>>> answer the long id of me >>>> end mouseUp >>>> >>>> ...and it'll do that, without affecting any other behaviors provided by >>> the parent script, or affecting any other objects that use the parent >>> script. >>>> >>>> Overloading is augmenting a behavior without replacing it. >>>> >>>> So if you wanted your custom controls (buttons "A", "B", etc.) to be >>> able to have their own mouseUp messages independent of any handling >>> provided in their parent behavior script, you could write the behavior with >>> either of two special forms of message handlers: before or after. >>>> >>>> The script of button "MyClass" could be revised as: >>>> >>>> after mouseUp >>>> answer the name of me >>>> end mouseUp >>>> >>>> ...and then the mouseUp message can be handled however you like in any >>> of the class instances ("A", "B", etc.), yet the behavior script will also >>> fire immediately after. >>>> >>>> The "before <message>" works similarly, but as you can guess those fire >>> before the child gets the message. >>>> >>>> Before and after handlers are limited to behavior scripts, as they were >>> added specifically to allow behaviors to augment actions without limiting >>> the scope of normal messages a subscribed object can act on. >>>> >>>> This may be a lot to take in all at once. >>>> >>>> Play with steps 1 to 11 to get going, explore ways to apply that to >>> your work. Later on you can add "before" and "after" handlers if you need >>> them. You may not (I rarely use them), but if you do need them they're >>> good to know about. >>>> >>>> Don your pith helmet and begin your adventure! >>>> >>>> -- >>>> 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 _______________________________________________ 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