Re: Chained Behaviors

Thanks Dave. Pete lcSQL Software Home of lcStackBrowser and SQLiteAdmin On Tue, Nov 4, 2014 at 2:59 PM, Dave Kilroy wrote: > Hi Pete > > It looks like they appeared in LC 6.1 > http://newsl

Re: Chained Behaviors

Hi Pete It looks like they appeared in LC 6.1 http://newsletters.livecode.com/july/issue152/newsletter1.php - "Some are born coders, some achieve coding, and some have coding thrust upon them." - William Shakespeare & Hugh Senior -- View this message in context: http://runtime-revolut

Re: Chained Behaviors

On 7/13/13 1:11 AM, Geoff Canyon wrote: Can you share this 200-line handler? No, they'd sue me. But if you can say why you're interested, I could probably describe it in generic terms. It isn't actually a single mouseUp, that was just the quickest way to describe it. It's actually a mouseUp

Re: Chained Behaviors

On 7/12/13 7:57 PM, Monte Goulding wrote: On 13/07/2013, at 10:37 AM, "J. Landman Gay" wrote: For which I am very grateful. Mark has an expansive vision and solid knowledge of both the language and the people who use it, and so far, I think everything he's decided has been spot-on. I trust hi

Re: Chained Behaviors

Can you share this 200-line handler? Sent from my iPad On Jul 12, 2013, at 3:31 PM, "J. Landman Gay" wrote: > One of the mouseUp behaviors is 200 lines long. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscri

Re: Chained Behaviors

Great thread. I think I got this inspiration from Jacque. Chained behaviors allow one to create a well defined sub-message hierarchy distinct from the ordinary one. You can, in other words, write your own message path, encompassing specific aspects of your program that make sense for it. Thi

Re: Chained Behaviors

On 13/07/2013, at 10:37 AM, "J. Landman Gay" wrote: > For which I am very grateful. Mark has an expansive vision and solid > knowledge of both the language and the people who use it, and so far, I think > everything he's decided has been spot-on. I trust him to make the right > decisions. I

Re: Chained Behaviors

On 7/12/13 6:08 PM, Monte Goulding wrote: Basically nothing gets in the engine unless it goes through Mark and he thinks it's both a good thing and ready. For which I am very grateful. Mark has an expansive vision and solid knowledge of both the language and the people who use it, and so far,

RE: Chained Behaviors

Richard Gaskin wrote... > As the number of contributors grows, the role of Community Manager can > be expected to outgrow Mark's availability, so I believe RunRev plans on > having someone to handle that soon. But in the meantime, when it comes > to stewarding the code base, right now Mark is

Re: Chained Behaviors

Peter Haworth wrote: I remember a while back you mentioned the need for a "Community Manager" (or something similar) in the open source world. Is Mark that person then? As the number of contributors grows, the role of Community Manager can be expected to outgrow Mark's availability, so I beli

Re: Chained Behaviors

On 13/07/2013, at 8:52 AM, Mark Wieder wrote: > "whoa! look at that!". Ah.. happy memories ;-) > >> If anything the open source move gives everyone a chance to become >> involved in feature development discussions and implementations to >> ensure all the Xtalk ducks are in a row. > > Absolut

Re: Chained Behaviors

On 13/07/2013, at 8:40 AM, Peter Haworth wrote: > If you read my later post, you'd see that I get the issue with the mouseUp > handlers, just wasn't clear from Jacque's original diagram. Right... I wrote that before Jacque's second answer came in and your response to it. > > As for the "what

Re: Chained Behaviors

Monte- Friday, July 12, 2013, 1:38:06 PM, you wrote: > a money for jam investment as far as RunRev was concerned. It was > just a case of out of sight out of mind until a few of us spotted > the tantalisingly named FEATURE_INHERITED_PARENTSCRIPTS ... Well, to be fair about that, the feature was

Re: Chained Behaviors

Monte, If you read my later post, you'd see that I get the issue with the mouseUp handlers, just wasn't clear from Jacque's original diagram. As for the "what's in it for me" issue, that wasn't my question. I simply asked for real life examples of the practical use of chained behaviors since I w

Re: Chained Behaviors

John- Friday, July 12, 2013, 12:12:45 PM, you wrote: > I understand 'behaviors', I use them quite a lot of the time... I > just don't see the need to continue with the 'chain' in xTalk... I You don't *need* to chain them at all. Just continue working the way you do and nothing changes. I think

Re: Chained Behaviors

Hi Pete: FWIW, a behavior script is not much different than using a library script, or front/backScript. It's a block of code that executed along the way of the message path but stays local to the object it is assigned to. In fact, one could *almost* say that behaviors are in some cases more app

Re: Chained Behaviors

For anyone who hasn't played with behaviors yet, try scripting something like this without them: Create a stack. Put ten small images on the card, each with a unique name. These are the sprites. The stack script should already have its own mouseDown and mouseUp handlers that do something unrel

Re: Chained Behaviors

On Fri, Jul 12, 2013 at 12:36 PM, Richard Gaskin wrote: > Having once had a disagreement with Mark Waddingham over a language design > issue, my respect for his good judgment in this regard was only amplified > by that momentary conflict. I remember a while back you mentioned the need for a "Co

Re: Chained Behaviors

Ah OK, that makes sense. I had the impression that each sprite needed mouseUp logic that was unique to it. I think I'm now seeing the usefulness of this. I'm thinking there might be a spot for a utility that, for any given control, lists the message handlers it uses and where they reside. Pe

Re: Chained Behaviors

On 13/07/2013, at 5:47 AM, Peter Haworth wrote: > OK, good example, thanks. I have to ask, though, why not have the unique > mouseUp handlers in the sprite scripts and a behavior script for the common > mouseDown handler? Because that would mean replication and more maintenance if there's a lo

Re: Chained Behaviors

Richmond wrote: On 07/12/2013 08:58 PM, Richard Gaskin wrote: Peter Haworth wrote: Has anyone got any real world examples of the benefits of the new chained behaviors feature? I just read the latest newsletter article about them and while I understand the concept, I didn't see benefit in the

Re: Chained Behaviors

On 07/12/2013 10:43 PM, John Dixon wrote: Richard I hear what you're saying about the risk of becoming too complex, and I agree we should evaluate such proposed extensions very carefully. On this we agree... with emphasis on 'very carefully'... In the end what I learned is that he's deep

Re: Chained Behaviors

On 7/12/13 2:47 PM, Peter Haworth wrote: On Fri, Jul 12, 2013 at 11:36 AM, J. Landman Gay wrote: Remember that behaviors are not a single handler, they are whole scripts. I have several sprites that require different behaviors on mouseUp but they all have the same behaviors on mouseDown. With a

Re: Chained Behaviors

On 07/12/2013 08:58 PM, Richard Gaskin wrote: Peter Haworth wrote: Has anyone got any real world examples of the benefits of the new chained behaviors feature? I just read the latest newsletter article about them and while I understand the concept, I didn't see benefit in the example scenar

Re: Chained Behaviors

On 07/12/2013 08:04 PM, Peter Haworth wrote: Has anyone got any real world examples of the benefits of the new chained behaviors feature? I just read the latest newsletter article about them and while I understand the concept, I didn't see benefit in the example scenario over a single behavior

Re: Chained Behaviors

On Fri, Jul 12, 2013 at 11:40 AM, Scott Rossi wrote: > have built a system that uses one behavior for a wide range of controls > using switch statements, and the higher the number of controls you have to > support, the more complex and messier the code gets. Chained behaviors > gives you another

Re: Chained Behaviors

I meant to say "individual", not "additional". Sorry 'bout that. On Jul 12, 2013, at 1:53 PM, Chris Sheffield wrote: > Because each sprite would then have its own script, which would be identical > to all the other sprites' scripts. Then if a change were needed, you'd have > to go in and modif

Re: Chained Behaviors

Because each sprite would then have its own script, which would be identical to all the other sprites' scripts. Then if a change were needed, you'd have to go in and modify each additional script. Quite a nightmare if you have hundreds of them.. Chris -- Chris Sheffield Read Naturally, Inc. ww

Re: Chained Behaviors

On Fri, Jul 12, 2013 at 11:36 AM, J. Landman Gay wrote: > Remember that behaviors are not a single handler, they are whole scripts. > I have several sprites that require different behaviors on mouseUp but they > all have the same behaviors on mouseDown. With a chained behavior, I could > have plac

Re: Chained Behaviors

On Fri, Jul 12, 2013 at 10:58 AM, Richard Gaskin wrote: > t obviates the switch statement. > > We could take this question one step back and ask why we'd want behaviors > at all, when we could just use frontScripts with switch statements instead. > > But that thought experiment (hopefully) makes

RE: Chained Behaviors

Richard > I hear what you're saying about the risk of becoming too complex, and I > agree we should evaluate such proposed extensions very carefully. On this we agree... with emphasis on 'very carefully'... > In the end what I learned is that he's deeply passionate about > preserving the e

Re: Chained Behaviors

John Dixon wrote: > Richard... > > I hear what you say, but does an xTalk language need to go down this > road ?... or to perhaps put a direct way... Should an xTalk language > be going down this road ?... What I am worried about is that there > are a lot of people jumping on the 'open source' ba

RE: Chained Behaviors

ther languages... so what ?! Dixie > Subject: Re: Chained Behaviors > From: jacques.cla...@gmail.com > Date: Fri, 12 Jul 2013 21:07:55 +0200 > To: use-livecode@lists.runrev.com > > John, > > in my opinion, behaviors is simplicity. You don't have to deal with the name

Re: Chained Behaviors

> > >> Date: Fri, 12 Jul 2013 10:58:29 -0700 >> From: ambassa...@fourthworld.com >> To: use-livecode@lists.runrev.com >> Subject: Re: Chained Behaviors > >> Nested behaviors simply extend the value of such a mechanism, at long >> last givin

Re: Chained Behaviors

thworld.com > > To: use-livecode@lists.runrev.com > > Subject: Re: Chained Behaviors > > > Nested behaviors simply extend the value of such a mechanism, at long > > last giving xTalk one of the most valuable aspects of OOP: subclasses. > > Richard... > > I hear

RE: Chained Behaviors

> Date: Fri, 12 Jul 2013 10:58:29 -0700 > From: ambassa...@fourthworld.com > To: use-livecode@lists.runrev.com > Subject: Re: Chained Behaviors > Nested behaviors simply extend the value of such a mechanism, at long > last giving xTalk one of the most valuable aspects o

Re: Chained Behaviors

In my case, I've been waiting years for something like chained behaviors. I create a lot of custom controls, and the limit of a single behavior per control was not enough. At the control level, I use functions and commands are exclusive to a single control. But at a higher level, I want a set of

Re: Chained Behaviors

On 7/12/13 12:04 PM, Peter Haworth wrote: Has anyone got any real world examples of the benefits of the new chained behaviors feature? I just read the latest newsletter article about them and while I understand the concept, I didn't see benefit in the example scenario over a single behavior wit

Re: Chained Behaviors

Peter Haworth wrote: Has anyone got any real world examples of the benefits of the new chained behaviors feature? I just read the latest newsletter article about them and while I understand the concept, I didn't see benefit in the example scenario over a single behavior with some common logic a

Re: Chained Behaviors

Hi Peter, Am 12.07.2013 um 19:04 schrieb Peter Haworth : > Has anyone got any real world examples of the benefits of the new chained > behaviors feature? > > I just read the latest newsletter article about them and while I understand > the concept, I didn't see benefit in the example scenario o