Chained Behaviors

[Peter Haworth]

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 <monte at sweattechnologies.com
> wrote:

>
> On 13/07/2013, at 5:47 AM, Peter Haworth <pete at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>