Best practices for intercepting events/having identical scripts in multiple fields?

[bogs]

I suppose, but it is likely my projects must fall way below the scope of what is considered

There may be other benefits, but these hit the highlights of why behaviors are so empowering for larger projects.

For what I do, the description sounds like more effort than it is worth.

However, that is neither here nor there, since I don't use them, and therefore don't know enough about them to even speak coherently about them, for the question posed by the OP what Craig and I presented could be considered as an option and certainly is something I've used quite often.

On the other side of that, I'm not sure I'd agree this part of what Richard said was any different or better than our alternate suggestion -

Portability comes from externalizing code. Whether as a button script in a library stack, or a script-only stack, I can maintain a single code base where fixes benefit everything I'm working on that uses it. With traditional copy-n-paste methods I'd need to go back to each copy and update, and hope I don't forget one.

I think whether your using behaviors, or whether your putting the script centrally in the message path, the above (portability) would apply equally, i.e. your still maintaining a single code base for those objects. I don't know why copy and paste is in there, neither I nor Craig suggested any such and it wouldn't be needed using the method we suggested any more than using a behavior would need it.

Consistent naming of controls would certainly be of benefit with the method I use, all the more so if the scripts are located farther away in the path than the group level let's say, but I think consistent naming is a benefit no matter what else you do. Even writing just straight up scripts, with in the object level, consistently naming your objects tells you at a glance the objects purpose.

However, I'm pretty sure from some of the code I've read that consistent naming of objects isn't something most people using Lc do. I sure didn't see it in any of the lessons I've read in Mc / Lc, nor have I ever seen it in any of the code I've read in any of the IDEs (unless your looking at variables).

[FourthWorld]

Sometimes I use behaviors. Sometimes I don't.

There's nothing religious here.

LiveCode is very flexible.

Use what works for you in the task at hand.

[bogs]

?

Just for the record, I thought I had said this earlier (but apparently not), I don't have a problem with behaviors, they just aren't a part of the IDE I use which is too old to have them. There isn't anything holy or divine in choosing to use method x to accomplish whatever your trying to accomplish, use whatever suits you. I think we both agree on that.

As well, no part of my intention in commenting on portability was in any way a slam on you, Richard, nor was I trying to pick apart any part of what you were saying, I was merely pointing out that on the topic of portability, I (personally) think it is a wash, and I posited why I think that.

Even if I don't (and probably never will) use behaviors per se, I still like to know if my own thinking is on straight or if I have indeed strayed off the cliff again ha I have no experience to speak of concerning behaviors, you have lots, so if my thinking is somehow squirrely, how would I learn that?

From my POV, the best way is state my thinking to someone that knows. If what I said is off, I sure hope you put forth the information telling me why.

On efficiency, I can see a slight edge going to behaviors, but it seems (from what you said) that flexibility is where the real advantage to using them might be, chaining and overloading are nice tools to have on occasion.

None of the above would imply a religious awe for any preference, people who have access too them certainly have an additional tool in the box. All I (and I believe Craig) were trying to point out is that there is always more than one way to skin a cat. More than any single tool, I think options in the way to do things should always be presented, and

[jacque]

@Bogs, I totally agree, there is no religious war here and asking for clarification is noteworthy. So I thought I'd just give an example here. I have a series of behaviors that I've implemented in one of my current projects. The project has a mainstack that runs everything and dozens and dozens of other stacks that are downloaded from a server on demand. Each of those stacks has a sequence of "quizzes" the user works through, which can involve any one of clicking, dragging, filling in blanks, or calculating numerical answers. We call these scripted objects "sprites".

Each type of sprite has distinct behavior which can occur anywhere in the whole system. Each sprite must respond to mouseEnter, mouseDown, mouseUp and mouseLeave, as well as additional messages that apply only to a specific type of sprite. The behavior for each mouse event is different for every sprite and some of the sprites have fairly involved scripts.

If I had incorporated all this into the mainstack, determining the target, branching for the correct type of reaction, and ignoring all mouse events that don't apply (not only in general, but to any particular type of sprite) would seriously complicate the mainstack's script. Since mouse events occur all over the place, nearly all of them would need to be filtered out if the user were only clicking to change cards, go to another stack, select from one of several indexes, etc.

Instead, I use four behavior scripts, one for each type of sprite. There are hundreds of those across all those stacks, but it was only necessary to assign a behavior to one sprite object and then duplicate it to get as many as a card required. The advantage here is not only relieving the mainstack script of some serious complexity, but also isolating the mouse events to only the particular target object. This saves a good deal of useless interaction with the mainstack script as well as preserving simplicity when editing. I do not have to trawl through all the branching of a huge mainstack script; instead, everything that relates to a single type of sprite is neatly encased in its own unique behavior script.

[bogs]

Good example Jacque but on the topic of portability, is my thinking way off? I don't mind going off the cliff often, but I don't like taking innocent bystanders with me

[FourthWorld]

I suppose if we isolate portability from other considerations, and reframe the OP's discussion to be strictly a comparison with library-based methods, one can indeed make a plausible argument that they're a wash.

My intention was to outline the benefits of behaviors, and portability in the context I gave hopefully shows the benefit over a copy-n-paste alternative, which was the example I was replying to.

Other options each have their own mix of pros, cons, and washes.

Use whatever works for you in the task at hand.

[bogs]

portability in the context I gave hopefully shows the benefit over a copy-n-paste alternative, which was the example I was replying to.

I think that is what confused me, I must have missed the copy and paste alternative you were referring too.

[SparkOut]

For me, I think there's no reason to mention OOP in connection with Behaviors, except that often people experienced in other OOP type languages will bemoan the lack in LiveCode or believe it to be inferior in some way. Behaviors can simulate some OOP methodology but LC doesn't have the same paradigm so it's moot for me.

We all agree, what works for you is best. I just can't help mentioning the simplicity of keeping track (or not having to keep track) of multiple controls, especially where there are many and dynamic, and not having to code for filtering by name/type/target or whatever.

Take this sample stack, flaring "synapses" in a brain at random, sending a single message to a random node and then letting the node's behavior deal with the recurrent messages to increase and decrease the brightness, while the next synapse trigger is generated in the group script. There are many other ways this could be approached, but this shows a simple and effective use of behaviors.

Behavior demo.zip

Image resolution reduced dramatically

(119.68 KiB) Downloaded 169 times