I'd like to see the 'the caller' added as well.

Mind you, I'd like to see a *lot* more of the player object bugs fixed and more of the LCS statements that are still not Unicode aware made Unicode aware first, but the "the caller" would probably 3rd on my list. Digging through the executionContexts is a pain even when possible and there are lots of places in my code where being able to fidn the caller would be helpful.


On 11/26/2019 10:59 AM, Trevor DeVore via use-livecode wrote:
About 15 years ago Dar Scott added a feature request to have a function
that returns the long ID of the caller's caller's object:

https://quality.livecode.com/show_bug.cgi?id=1954

Two years ago LiveCode Builder added `the caller` which does just that, but
only in LCB. If anyone is looking for a contribution to make to the engine
I am throwing this out there as something to consider: Add `the caller` to
LCS.

Why is this useful?

When writing handlers that send callback messages it is sometimes desirable
to send the message to the object that called the handler. For example,
let's say I have a library that makes REST calls to a server API. This
calls are asynchronous so a handler in the library will need to notify the
caller that the request is finished. If a handler from the library was
called  from a card then I might want the callback to be sent to the card.
If a handler was called from a group then I might want the callback to be
sent to the group.

The current solution is to pass the long id of the object you want the
callback sent to as a parameter to the library handlers. For example:

restAPIGetObjects tId, the long id of me # callback will sent to me

If you aren't using password protected stacks then you can use `the
executioncontexts` to get the information you need to determine the caller.
But when a stack is password protected the necessary information isn't
included in `the executioncontexts`.

I have a recent real world example. I rewrote the REST API interface in an
application I work on to use behaviors that I attach to cards in my UI
stacks. The design allows me to segment REST calls made within a specific
object (card or group) so that callbacks and cleanup are very simple to
manage. The need to pass the long id of the caller as a parameter if I want
the callback for a specific handler to be sent to a group on the card
shouldn't be part of a handlers parameter list, however.



_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to