Adding `the caller` to LiveCode Script

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Adding `the caller` to LiveCode Script

Mark Wieder via use-livecode
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.

--
Trevor DeVore
ScreenSteps
www.screensteps.com
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Adding `the caller` to LiveCode Script

Mark Wieder via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode