OpenCard to control?

[Zax]

Once again, I cannot judge the validity of the diagram but I think that it is useless to add the notions of "before" and "after" which are very particular and which would harm the understanding of the general message path.
For me, this diagram should strike a good balance between accuracy and clarity, so that it covers most needs. That it can both help general understanding without being too simplistic.
Perhaps the notions of "before" and "after" should appear as a small note on the diagram.
I would also add another note to clarify that the "control events" are like "openCard", "resumeStack", etc.

The most complete representation is a vast spiderweb of connections, less instructive than a simplified model designed for learning core concepts.

I agree, and the last diagram created by Stam seems perfect to me (the first one I posted was much too simplistic).

[stam]

Thanks Brian - I'll respond to your nice example later, once I've had a chance to test something.

I hope you don't mind me quizzing you on this, because to my mind it still doesn't make sense... and I'd like it to

'before' and 'after' don't change the message path. They are additional messages that get handled without altering the standard message path. Regardless of what the 'before' handler does the message goes to the object normally.

The path does change with 'before' - the handler in the behavior is executed first, then the handler in the object, which is not the normal message flow as I understand it.

Regardless of what happens in the object, the 'after' handler is called before the message goes past the object

This I don't understand. I fail to see the logic in saying this all happens before it goes past the object?
If 'after' is called after the message is in the object, then effectively the message is handled in the behavior, not the object. It doesn't go back to the object it either stops in the behavior or is pushed up the message path. Or have I misunderstood?

One possibility is the "on" is the default action for the behavior. It could be overridden by the control. The developer may also want something to happen even if the default handler was overridden and would use the "after" to do so.

My point is if you are in the same script always executing the same process with an 'on' followed by an 'after', you might as well handle everything in one of the two. Yes you can do as you say, but I fail to see any benefit whatsoever, other than perhaps splitting a super long handler into two...
Then again LC lets us do *lots* of things we shouldn't be doing lol

[bwmilby]

My comments about the message path are a paraphrase from the documentation:

A before handler allows developers to produce behavior scripts which can handle messages sent to a control without having any effect on the message path, unlike front and back scripts.

So, yes, the message does travel a slightly different path, but it doesn't permanently change it. The 'before' and 'after' supplement the path without changing what would happen if they were not present. They do not have the ability to intercept/trap/handle the actual message. I don't like the quote because it says they 'handle' the message, but the message isn't considered 'handled'. Back scripts are a bad analogy since they only work if the message isn't handled already.

My comments on 'after' only really mean anything if the message is not handled. If the object/behavior ends the 'on' handler with a pass (or doesn't handle the message), then the 'after' handler will fire before the message continues past the object (up or down depending on your orientation). If the object/behavior handles the message, then the 'after' still fires but that is the end of the message as it was handled.

[stam]

My comments about the message path are a paraphrase from the documentation:

A before handler allows developers to produce behavior scripts which can handle messages sent to a control without having any effect on the message path, unlike front and back scripts.

So, yes, the message does travel a slightly different path, but it doesn't permanently change it. The 'before' and 'after' supplement the path without changing what would happen if they were not present. They do not have the ability to intercept/trap/handle the actual message. I don't like the quote because it says they 'handle' the message, but the message isn't considered 'handled'. Back scripts are a bad analogy since they only work if the message isn't handled already.

My comments on 'after' only really mean anything if the message is not handled. If the object/behavior ends the 'on' handler with a pass (or doesn't handle the message), then the 'after' handler will fire before the message continues past the object (up or down depending on your orientation). If the object/behavior handles the message, then the 'after' still fires but that is the end of the message as it was handled.

OK, I think we're on the same page... just saying the same thing differently

That being said... how would you like to see that inset graph changed?
the latest version seems fine to me, and not really saying anything different from what you say.

[bwmilby]

OK, I think we're on the same page... just saying the same thing differently

That being said... how would you like to see that inset graph changed?
the latest version seems fine to me, and not really saying anything different from what you say.

I agree, the flow for behaviors is a bit complicated and difficult to accurately reflect in a graph. I tried to think of any alternatives last night but they just ended up being messy trying to put more detail in. The only possible change could be to make the red arrow return to the top.

[stam]

The only possible change could be to make the red arrow return to the top.

It already does?
Or perhaps that needs to made clearer?

[bwmilby]

It points up to the control. I was wondering if it should loop back and point down to the control (or even just back to the message path line).

[stam]

It points up to the control. I was wondering if it should loop back and point down to the control (or even just back to the message path line).

Hmmm, I'm not sure looping down up and down again (if I understood correctly) benefits... the graph gets cluttered with (in my mind) unnecessary lines/arrows.

Instead, how about this: I"ve increased the emphasis on the main path and have added "Back to normal path" to the red arrow going back up, to denote that the flow form there on is restored. I've also removed the "pass" from main path, because that's implied/true of every step, so really is superfluous...

The point of the graphis just to illustrate how a behavior/nested behaviors can be inserted into the path of a message with "before", "on", and "after". To me this achieves that with simplest possible digestible graph... Unless I'm making any grievous errors, I'll just leave that as is, because I really want to keep the graph as digestible as possible...