Adding `the caller` to LiveCode Script

Paul Dupuis paul at researchware.com
Tue Nov 26 11:15:39 EST 2019


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.
>





More information about the use-livecode mailing list