Re: Behaviors and the message path

>> Mark wrote: >> So... Either I'm not crazy or I've got company. > > Bob wrote: > 2 other options. Neither of you is crazy. Both of you are crazy. These are not 'other' options!? Both cases are already included in the listing of Mark. Or is it a typo, did you mean "2 other options:"?

Re: Behaviors and the message path

2 other options. Neither of you is crazy. Both of you are crazy. What do they teach children in logic classes these days?? ;-) Bob S On Dec 9, 2016, at 18:25 , Mark Wieder > wrote: I think of them as private backscripts, available only the

Re: Behaviors and the message path

Thanks for taking the time to explain this Mark. After I thought about it for awhile I expected that this would be your answer and again I’m very pleased with how you’ve implemented the behavior feature. Tim Bleiler, Ph.D. Instructional Designer, HSIT University at Buffalo > On Dec 12, 2016,

Re: Behaviors and the message path

On 2016-12-09 19:44, Bleiler, Timothy wrote: I still have one question though. Given the part of your answer I quoted above, why does the “pass” control structure trigger handlers along the behavior chain rather than skipping over them and going to the next object in the ownership chain?

Re: Behaviors and the message path

Actually I got the idea from you. But so far it seems to hold. Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 9, 2016 8:27:18 PM Mark Wieder wrote: On 12/09/2016 03:15 PM, J.

Re: Behaviors and the message path

On 12/09/2016 03:15 PM, J. Landman Gay wrote: On 12/9/16 4:47 PM, mwieder wrote: But at any rate, I believe conflating "extending" a script with "concatenation" is the wrong way to think about behaviors. I think of them as private backscripts, available only the object to which they are

Re: Behaviors and the message path

On 12/9/16 4:47 PM, mwieder wrote: But at any rate, I believe conflating "extending" a script with "concatenation" is the wrong way to think about behaviors. I think of them as private backscripts, available only the object to which they are attached. If the behavior doesn't catch a messages,

Re: Behaviors and the message path

Tim Bleiler wrote > Maybe I didn’t explain what I’m actually doing correctly or we’re just > doing something different, but after I assign the behavior I do NOT get > the same result. Er...yes, you're right. That's what happens when I try to multitask and type without thinking. The other project

RE: Behaviors and the message path

mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of J. Landman Gay Sent: Friday, December 09, 2016 3:22 PM To: How to use LiveCode Subject: Re: Behaviors and the message path On 12/9/16 1:49 PM, mwieder wrote: > ...and I want to echo your appreciation of Mr. Waddingham's > stewards

Re: Behaviors and the message path

> On Dec 9, 2016, at 2:44 PM, mwieder wrote: > > I think it's wrong to consider behavior scripts as concatenated onto the end > of a script. If you rather think of the behavior script as a library or > backscript, then the message path becomes a little clearer. Thinking

Re: Behaviors and the message path

On 12/9/16 1:49 PM, mwieder wrote: ...and I want to echo your appreciation of Mr. Waddingham's stewardship of the xtalk legacy. I have argued (and will continue to do so) with him about fine points of interpretation and future direction of the language, but I always appreciate his constant

Re: Behaviors and the message path

...and I want to echo your appreciation of Mr. Waddingham's stewardship of the xtalk legacy. I have argued (and will continue to do so) with him about fine points of interpretation and future direction of the language, but I always appreciate his constant conservative approach to making changes

Re: Behaviors and the message path

Tim- I think it's wrong to consider behavior scripts as concatenated onto the end of a script. If you rather think of the behavior script as a library or backscript, then the message path becomes a little clearer. In your example 2, the message "you are in Script 3" appears because that instance

Re: Behaviors and the message path

On Dec 9, 2016, at 12:56 PM, Mark Waddingham > wrote: Rule (2) preserves this semantic for behaviors and, indeed, codifies the fact that behaviors aren't really objects - they are script extensions (for want of a better term). Thank you Mark, your

Re: Behaviors and the message path

On 2016-12-08 21:23, Bleiler, Timothy wrote: I’m curious about what appears to me to be a confusing aspect of the implementation of behaviors. In short, behaviors have characteristics of an isolated, local extension of the message path AND characteristics of a concatenation of the parent

Re: Behaviors and the message path

On Dec 8, 2016, at 10:31 PM, Mark Wieder > wrote: I think the best explanation of the message path is still Richard Gaskin's chart and web page. Although I have to give props to Dar Scott for his message primer as well. I tend to think of

Re: Behaviors and the message path

On 12/08/2016 04:40 PM, Bleiler, Timothy wrote: Thanks Mark. I probably shouldn’t have used the word “problems” anywhere in my post. I agree, there are terrific benefits with the current implementation of the behavior feature. My main concern was insuring that what I observed was intended. If

Re: Behaviors and the message path

I think I need an example, because I'm not understanding the problem that you're having with the currentbehavior On Thu, Dec 8, 2016 at 7:40 PM, Bleiler, Timothy wrote: > > On Dec 8, 2016, at 5:09 PM, mwieder wrote: > > > > I don't see these as

Re: Behaviors and the message path

> On Dec 8, 2016, at 5:09 PM, mwieder wrote: > > I don't see these as anomalies or inconsistencies, but as features that help > implement proper object-oriented behavior. Tim- what "problems" do you see > with the way this is implemented? Am I missing something? Thanks

RE: Behaviors and the message path

(Different Mark here, but...) Yes, that's by design and explicitly to allow for overriding. It's *very* useful, for example, for setting up default behavior in a behavior script and then selectively overriding that in some, but not all, the objects that use that behavior script. The issue of

RE: Behaviors and the message path

> Tim Bleiler, Ph.D. wrote >if the same handler name is present in the behavior script and the parent >script, the parent script handler is >the one that runs. Wow! This is good to know. This could be very handy overriding a behavior handler for a specific control. As you said, there seems to