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 wasn't seeing anything particularly useful in the simple newsletter example. Now the good people on this list have enlightened me and I see the use cases. Although I don't have a personal need for chained behaviors that I can think of right now, I will certainly be aware of them for future projects. Pete lcSQL Software <http://www.lcsql.com> On Fri, Jul 12, 2013 at 1:38 PM, Monte Goulding <mo...@sweattechnologies.com > wrote: > > On 13/07/2013, at 5:47 AM, Peter Haworth <p...@lcsql.com> 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 lot > of sprites with the same handler. > > Here's an idea... why don't we put all our code into big switch statements > in the mainstack script... that sounds like fun ;-) > > I've got another use case. The mApp framework is a behavior script for the > mainstack of the app. It has a small amount of code that's only in there > for development support... standalone building, drag and drop of images > onto the app etc. This code really shouldn't be in the built app. With > chained behaviors I can put it in a support behavior that doesn't get's > copied to the stackfile during the build. > > Most of my behaviors are based on the same boilerplate template so there's > lots of common code. If I could move most of that to a parent behavior I'd > be very happy to do so because any fixes would be applied to all... > > Like Richard I've been waiting for this for years. One of my biggest > gripes about LiveCode is that it's sometimes hard to avoid replicating the > same code all over the place. If you need to change something then you need > to change it everywhere. It's easy to introduce bugs there because you miss > one or two spots where you didn't change the code. > > Whenever there's a significant new feature added to LiveCode there's > always a certain about of "what's in it for me" going on on this list. > People want the things they need to be higher priority. Well the good news > on this one is it was all implemented when behaviors were first introduced > and was just #ifdefed out. So it was 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 > ... > > There seems to be a certain element that believe that Mark Waddingham is > the only thing holding back a tide of open source contributors that want to > turn LiveCode into a low level language and ruin your platform. It's just > plain untrue and I think it's a very harmful attitude to have. Why not stop > and think what might motivate someone to put their spare time into working > on the engine? 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. > > Cheers > > -- > Monte Goulding > > M E R Goulding - software development services > mergExt - There's an external for that! > > > > > > _______________________________________________ > 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
