LiveCode Forums

I've found a few use cases where I want to dispatch a message to an object but I only want that particular object to handle it. So the message should not pass down the hierarchy.

I propose: When without passing is specified even if the message is handled and explicitly passed in script it should not be passed thus differentiating the behavior from wrapping a send command in try/catch.

Use Case 1:
lcVCS dispatches lcVCSExport to each control so it can reset itself to defaults. This results in a flooding of the lower parts of the message path with unhandled messages.

Use Case 2
mergDataGridScroller is a wrapper behavior for datagrids to handle some mobile behaviors like scrolling. I'm implementing a couple of touch gestures (swipe, long touch) and want to dispatch to both the row control and the data grid without the datagrid getting both messages if the row control doesn't handle them.

It looks like what I want to do is as simple as either using the handleself method or passing nil in the pass_from parameter of handle. I'm not really sure why the pass_from object is a parameter of handle though because it's replaced by this in each recurse... Seems like it could just as easily be replaced with a boolean indicating whether to pass or not.

Not sure if we want the option to skip frontscripts too? That doesn't bother me or impact either of my use cases. Passing along the behavior heirarchy should be allowed I think and handleself already does that.

monte wrote:I've found a few use cases where I want to dispatch a message to an object but I only want that particular object to handle it...

Another approach is to check whether the object implements the command before dispatching.
Note that the conciseness in the code above depends on the approval of Jan's new filter.
But you could make do with current syntax.
But I'd rather use your proposed syntax for this than using filter.

-- Dick

I must confess I'm a little wary about this as it's introducing another kind of message send which breaks the existing expectations with regards the flow of messages through the message path.

Use Case 1 sounds like mainly an efficiency one - and in this case it would be better to start figuring out a good way to introduce a cache so that unhandled message sends don't incur a cost (after the first time, at least); and in the short term this could be mitigated by requiring a custom control to declare it wants the lcVCS messages to be sent to it. Additionally, a message cache of this sort would also allow us to remove the (pragmatic but slightly irksome) rules about some messages only getting sent when the object implements them.

Use Case 2 is, however, potentially slightly more interesting - I take it the row controls in this case aren't children of the datagrid? If they aren't then you can dispatch to one, check 'it' to see if it was handled, and if not dispatch to the other. If they are parent-child why can you not just let the message pass?

Both use cases have issues with people doing the wrong thing and therefore messing things up...

Case 1... someone implements a handler in an object with children that doesn't check if the target is me therefore drastically reducing performance...
Case 2... someone implements a handler in the row control behavior that doesn't pass the message

Right... However, both those justifications are just errors on the 'someone' (i.e. the developer) part that would need to be fixed.

In case 1 you are talking about a custom control developer - it would be part of the contract of the control with lcVCS that they should either declare they need the processing messages (perhaps by a bool custom property) in which case they must implement them and not pass.

In case 2 it sounds like it goes against the usual way of things. For example, the engine sends a mouseUp message to a control in a group - its up to the developer to decide whether to handle it there, or to handle it in the parent and whether to pass or not - isn't this just the same case? (I might be missing something).

I'm not wild about this either, because it breaks the object model for message passing.
Ruby deals with this situation through the "method_missing" method of a class, which keeps the object model intact.

Case 3
This option would be suitable for a publisher/subscriber pattern library

I think we can manage without it but I also think there are cases where it would be useful to send a targeted message and gracefully deal with whether the target object handled it or not.

A publish-and-subscribe library would deal with this neatly. I hesitated to suggest it because it's more at the IDE level than at the engine level, and because it adds a bit of extra complexity to handling messages, but I think it ties in very well with the IDE Contributors "First" discussion.

The thing is so we want a publish and subscribe library to inadvertently subscribe all parent objects to the passed message? I'd argue that if we are subscribing to a message outside the message path that only the subscriber should get it.

The thing is so we want a publish and subscribe library to inadvertently subscribe all parent objects to the passed message? I'd argue that if we are subscribing to a message outside the message path that only the subscriber should get it.

However, if an object has subscribed to a given message then it should handle it. If it doesn't handle it or pass it then it must mean that the developer has decided they want to handle it higher up.

Hmm... I can tell I'm not going to win this one...