Call, Send, Dispatch message source object

[WaltBrown]

I'm having a senior moment...

If I use Send, Call, or Dispatch between independent stacks, how does the message handler identify the source of the message? I know I've seen it somewhere (I've used it in the past) but now can't recall the answer...

Thanks, Walt

[dunbarx]

Walt.

Are you thinking of the fact that "dispatch" command can return information about whether the message was handled or not, or passed?

Craig Newman

[WaltBrown]

Thanks Craig. No. Here's a better description.

I have a number of utility stacks I use when parsing multilingual and/or multimedia content, for things like vocabulary testing, significant phrase or named entity identification, spell checking, statistics, protocol compliance, etc. They are each independent (and run under the IDE at the moment).

Many of them may call functions or send messages to each other (I am moving toward sending async messages to each other to reduce dependencies and allow throttling). A given utility stack may not know which other utility stack sent the message. I am hoping to avoid having to include the sender's ID in each message's parameter list, as I thought it was already available. But that might be my muddled memory recalling a different programming language.

[bangkok]

Try :

Code: Select all

   answer the long owner of the target

[dunbarx]

@Bangkok

answer the long owner of the target

This would give the owner of the target stack, no?

@Walt. I am not sure there is a "receipt" for the sending handler or its environment. I could be wrong. When Bangkok, posted, unless I am misunderstanding him, I initially thought it was a wonderful coup. But I do not think that is what you need. You may indeed have to send that receipt along with any parameters.

Oh, yes. I could be wrong.

Craig

[FourthWorld]

You can obtain info about the calling chain from the executionContexts, but I wonder if maybe what's really needed here is to consider driving this with behavior scripts.

[dunbarx]

AHA! Richard makes a point. Behaviors would also allow each button to execute its own particular actions, just like a group script, but more importantly, the local variable "me" would refer to the child object. By testing "me", or the owner of "me", you can derive the source button info without having to send that data along with the message.

Much more modern way to do things...

Craig

[WaltBrown]

Thanks. Bangkok, "owner" gives the owner of the handler in the receiving stack.

Richard, thanks, same thing, "executionContexts" in the handler only gives info about the receiving stack.

On behaviors, how would that work? Would the behavior live in the stack that will eventually receive the message? In that case I would still need advance knowledge of the sending stack in the receiving stack, which I don't have. Or the stacks would have to register with each other to "collect" appropriate behaviors for the context.

[WaltBrown]

I guess I'm back to this discussion from last month:
http://forums.livecode.com/viewtopic.ph ... lit=pubsub

[mwieder]

Walt- I'm missing something about

Richard, thanks, same thing, "executionContexts" in the handler only gives info about the receiving stack.

The executionContexts gives you the call stack, showing exactly what chain of events led to the current state. If you examine it, you'll see the original caller, and everything else in the chain, including the long id of the objects.

[WaltBrown]

Thanks, you are right. I was trying it out in an existing set of stacks which was overcomplicating my logging. I made a test set of two stacks with just the calling code and saw that I was wrong, and it did get the entire context.