OpenCard to control?

[stam]

Or maybe it's a bit cleaner to de-emphasize behaviours?

[bwmilby]

I’m not sure you can really represent behaviors cleanly like that. They don’t sit where they are drawn completely. In addition to catching messages that are not present in the object you can also have “before” and “after” handlers that fire before/after the handler in the object.

One other caution - when you have a group set to "behave as a background", then it gets inserted in the message path as shown. If you only want it to capture messages for itself (when multiple backgrounds present), you must test for that and pass if appropriate. Here's one of my handlers where I do this:

Code: Select all

on preOpenBackground pBackgroundID
   if the id of me is not pBackgroundID then pass preOpenBackground
   updateStatus "preOpenBackground" && the short name of me & lf
   if sInitialized is not true then __Initialize
end preOpenBackground

I ran into this because I needed the messages to know when the background was opened but also had multiple groups that needed this treatment.

[stam]

I’m not sure you can really represent behaviors cleanly like that. They don’t sit where they are drawn completely. In addition to catching messages that are not present in the object you can also have “before” and “after” handlers that fire before/after the handler in the object.

Thanks Brian,

The intention is to show the default message path. Catching messages not in the path can be done in all locations really, the point isn't to map all possible combinations, just the default hierarchy, as a number of incomplete versions are out there…

Behaviours were included in this simply to
A) show that most objects can have behaviours that are inserted into the message path
B) the behavior will process a message after the object carrying them by default (unless using the before keyword of course)

I don’t think a single graph can show all possible message paths, but then again that isn’t the point of this. It’s just meant to be a high level guide of the default message path to complement the problem raised above.
I guess I could include bidirectional arrows for behaviours but would risk being too complex to be helpful. There may be a way to represent this in the graph but not sure that would not hopelessly complicate it…

Any suggestions?

[bwmilby]

I like having them in the muted color like your last one. I think an info box at the bottom with some of the caveats that should be considered would work.

Behaviors support the before/after control structures which allows developers to produce behavior scripts which can handle messages sent to a control without having any effect on the message path

Also, the messages from all other mainstacks will also go to the Library stacks.

[stam]

I like having them in the muted color like your last one. I think an info box at the bottom with some of the caveats that should be considered would work.

Behaviors support the before/after control structures which allows developers to produce behavior scripts which can handle messages sent to a control without having any effect on the message path

Also, the messages from all other mainstacks will also go to the Library stacks.

Thanks Brian - adding text is the obvious way, but the focus of this is visual representation.

As to library stacks - I found that library stacks can’t use other library stacks unless specifically loading the libraries with “start using”, which in effect puts them on their own message path.

Of course in daily usage, this is is nearly interchangeable, but strictly speaking, I think this creates a new message path that follows this exact same flow, only the input that starts it is on libraryStack.

On the other hand, regardless if a stack has “started using”, all messages hit the back scripts and I’ve used this as a lazy way of using multiple libraries without a specific stack loading these, hence the flow noted…

[stam]

As a solution to that last point, I’ll change the “from other stacks” to “from other message paths”. Hopefully this will reduce confusion?

As to the former, given that I would like this as visual as possible, I think I’ll ad a small inset graph showing before/default/after, that may work better…

[stam]

I like having them in the muted color like your last one. I think an info box at the bottom with some of the caveats that should be considered would work.

Behaviors support the before/after control structures which allows developers to produce behavior scripts which can handle messages sent to a control without having any effect on the message path

Also, the messages from all other mainstacks will also go to the Library stacks.

Hi Brian,
What do you think of having this as an inset graph to accompany the main graph?
Obviously open to corrections...

[Zax]

Great job Stam!
I propose a small graphic correction, for greater readability:

[stam]

Well arguably, StartUp is still an event, so not sure that merits its own header - can't list every single event generated in LC!
I presume StartUp bypasses the frontScripts, as it's sent to card 1, but not sure...

The 3 annotated events here are special inasmuch as they can bypass the default path.
Happy to make the change if others agree though.

For now, this is the updated graph (open to corrections/suggestions!):

PS: This is made in OmniGraffle, one of the best apps on Mac. Happy to share the OG file if anyone wants...

[bwmilby]

Hi Brian,
What do you think of having this as an inset graph to accompany the main graph?
Obviously open to corrections...

I like the idea. I actually threw a stack together last night to test/verify flow. That side route should be “not in” but before/after still will get called. If you pass in the object, then both “on” handlers will fire before the “after” one will. If you pass in the behavior, then the “after” will fire and then message heads on. Without the pass, the message stops. I did not test a second level to see if you can pass before/after.

[stam]

I like the idea. I actually threw a stack together last night to test/verify flow. That side route should be “not in” but before/after still will get called. If you pass in the object, then both “on” handlers will fire before the “after” one will. If you pass in the behavior, then the “after” will fire and then message heads on. Without the pass, the message stops. I did not test a second level to see if you can pass before/after.

Thanks Brian - that's a bit too complex a read in the middle of my normal (non-coding) working day, so I'll have to try and digest your comments and think how best to represent in a graph. But I may have to come back to your for clarification...

I find creating things like these hugely helpful for me and I hope may help others - your input is greatly appreciated...
Stam

[stam]

I like the idea. I actually threw a stack together last night to test/verify flow. That side route should be “not in” but before/after still will get called. If you pass in the object, then both “on” handlers will fire before the “after” one will. If you pass in the behavior, then the “after” will fire and then message heads on. Without the pass, the message stops. I did not test a second level to see if you can pass before/after.

Hi Brian,
I'm still a little unclear on what you're saying here...

Can you please elaborate on

That side route should be “not in” but before/after still will get called.

I'm not sure I understand this?
I now realise the right side-arm ('Handled in object 1') is wrong and should be removed, not sure if that's what you mean?

As I undestand behaviours (and my understanding may well be flawed, will not have time to test for the next 6 weeks or so):

• a message hits the object first and if not stopped then the behaviour second
• the message can be managed in the object first and if passed gets managed in the behaviour second. If not passed, it stops at the object.
• if a message is not handled in the object it will go up the object hierarchy and can be handled directly in the behaviour
• the 'before' handler in the behaviour reverses this and manages the message before the object and then (automatically?) passes to the object, restoring normal message path (ie can be stopped, passed or handled again in behavior with 'after').
• the 'after' handler in the behaviour fires after the message has been handled in the object regardless if passed (otherwise I can't really see the point as you could just handle the message in the object and then pass it to the behaviour...).
  In other words, I understand the 'after' script as equivalent to a handler in the object (empty or not) that passes the message so it's handled in the behaviour.
• I don't understand why a behaviour script would have both an 'on' and an 'after' handler in the same script - but assuming there is an important reason of some kind, then yes, the 'after' handler will, but this should be self explanatory (and unnecessary in my view!). And it doesn't really change the object hierarchy...

Do feel free to correct any misconceptions I may have!



On a related note:
Thinking more about this I'm not sure this message path is correct anyway.
I borrowed the basic hierarchy from existing examples without thinking... but none of the existing examples are correct as not all events are the same but I guess for simplicity these are just lumped together as 'other events'. Admittedly I copied the exisitng examples incorrectly as they do distinguish between group/card. But most do not have events directed at controls (eg newButton) so are incorrect in that.

Some are card/stack specific and bypass controls/groups (if they didn't you could just manage 'openCard' in a control or group, but you can't - that's why we have 'openControl').

I'll have to re-think this and probably add at least 2 if not 3 groups of events at the topmost level - eg control-orientated events, group events and card/stack events. In other words, Zax was on the right track with this recommendation above.
Are there any events that are sent directly to stack and bypass card?

Listing the events in this way would mean the openControl/openBackground/startUp side arms would not be needed and could be presented top-down instead, in a similar way to what Zax suggested for 'startup'.

Stam

[stam]

I've modified the chart to hopefully approach accuracy... sadly can't experiment to confirm for a few weeks, but do point out any errors...

[bwmilby]

Let me reply with code. Consider the following code that will be in each of 3 buttons and the card:

Code: Select all

before mouseup
   put "before mouseup" && short name of me && short name of this me & lf after fld "Log"
   pass mouseup
end mouseup

on mouseup
   put "on mouseup" && short name of me && short name of this me & lf after fld "Log"
   pass mouseup
end mouseup

after mouseup
   put "after mouseup" && short name of me && short name of this me & lf after fld "Log"
   pass mouseup
end mouseup

Buttons are named "Button", "FirstBehavior", and "SecondBehavior". "Button" has "FirstBehavior" set as its behavior. "FirstBehavior" has "SecondBehavior" set at its behavior.

The "before" and "after" handlers are ignored in "Button" and the card. Here is the result of clicking "Button" in the log field:

Code: Select all

before mouseup Button FirstBehavior
before mouseup Button SecondBehavior
on mouseup Button Button
on mouseup Button FirstBehavior
on mouseup Button SecondBehavior
after mouseup Button FirstBehavior
after mouseup Button SecondBehavior
on mouseup card id 1002 card id 1002

I don't think it is particularly useful to have "on" and "after" in the behavior, but just wanted to show the edge case. Without "pass", any of the same message below would not get processed (i.e. you will always see at least one "before", "on", and "after")

[bwmilby]

Can you please elaborate on

That side route should be “not in” but before/after still will get called.

I'm not sure I understand this?
I now realise the right side-arm ('Handled in object 1') is wrong and should be removed, not sure if that's what you mean?

Yes

• the 'before' handler in the behaviour reverses this and manages the message before the object and then (automatically?) passes to the object, restoring normal message path (ie can be stopped, passed or handled again in behavior with 'after').
• the 'after' handler in the behaviour fires after the message has been handled in the object regardless if passed (otherwise I can't really see the point as you could just handle the message in the object and then pass it to the behaviour...).
  In other words, I understand the 'after' script as equivalent to a handler in the object (empty or not) that passes the message so it's handled in the behaviour.

'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. Regardless of what happens in the object, the 'after' handler is called before the message goes past the object (if handled, then the 'after' is the last action for the message, if passed or unhandled then it continues normally once the 'after' handler finishes).

I don't understand why a behaviour script would have both an 'on' and an 'after' handler in the same script - but assuming there is an important reason of some kind, then yes, the 'after' handler will, but this should be self explanatory (and unnecessary in my view!). And it doesn't really change the object hierarchy...

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.