'send' and behaviors

[Graham Samuel]

Thanks to Mark and Dar for your replies. I'm afraid I didn't explain myself clearly, and I chose a stupid example of what I thought was the 'wrong' card reference, which obscured my real problem, which is this - the handler which I've called "doSomething" was written to take advantage of the context of the card it belongs on, so there are lots of references to objects like

  put someFunction (fld "myField1") into fld  "myField2"

and a lot more complex stuff involving lists of object names etc. Obviously in this context I don't have to write

  fld  "myField2" of me

or anything to set the context of the object name, because the path to the object (the field in my example) is implied. What I was trying to do was to recreate the context from outside the card, so that this type of coding would still work. I naively assumed that if the defaultStack is changed by the 'send', then the defaultCard (OK I know there is no such language reference in LC but you know what I mean) would be changed too. In fact what happens is that the new current card is simply the last card to be 'shown' in the new stack. Really I don't even want to change stacks, just cards. My simplification also obscured the fact that what I really do from card "A" is to

 send "doSomething" to grp "someGroupedControls" of cd "B"

but I don't think this changes anything.

AFAICS I will simply have to put overt references into my handlers of this type, which is a bummer because there are a lot of them. This would I suppose be solved if I did something like

 go card "B"

to start with (since it sets what I call the defaultCard), but then I would have to devise a mechanism for getting back to card "A" after the handler is executed, which looks pretty ugly to me - but of course I could be wrong, since I so often am.

Well, you learn something new every day.

Thanks again

Graham


On Sat, 2 Jun 2012 18:05:30 -0600, Dar Scott <dsc at swcp.com> wrote:

> This can be confusing.  I think it is the word "this" that causes confusion.  The behavior is strange in that "this stack", meaning the current stack, will change even when it is not foremost and even if it is invisible or deleted.  At times some folks naturally expect that and at times some other folks might expect otherwise before seeing how it works.  As you said, the important thing is to use 'me'.  We need a built-in object reference like 'the stack of me' or 'my stack'.  We can write our own "longIDOfStackOfMe()" function, I guess.
> 
> In addition the message path moves to the target object.  
> 
> Dar
> 
> 
> On Jun 2, 2012, at 4:37 PM, Mark Schonewille wrote:
> 
>> Hi Graham,
>> 
>> A card is not a stack (obviously). The stack containing the card temporarily becomes the default stack, but "this stack" still refers to the currently visible card of the stack rather than the card containing the script. If you really want to refer to the card containing the script (or the behavior) then you need to use "me" (field x of me, the owner of me) instead of "this card".
>> 
>> On 3 jun 2012, at 00:28, Graham Samuel wrote:
>> 
>>> It says in the LC docs for the 'send' command:
>>> 
>>>> When the send command is used the stack containing the target handler temporarily becomes the defaultStack. All object references in the message are evaluated in the current context i. e. the defaultStack. Therefore references within the message that refer to "this card" or "this stack" will be referring to the card or stack where the target handler is located. 
>>> 
>>> I am relying on this: I have a line like this in a script on a particular card, say card "A" - in fact this line is in a behavior of the card:
>>> 
>>> send "doSomething" to card "B"
>>> 
>>> This works in the sense that the handler "soSomething" is executed, but if I include a line in the handler:
>>> 
>>> put "This card is" && (the short name of this card)
>>> 
>>> I get the name of the sending card (A), not the name of the target (B) - as a result the handler doesn't have its expected context and fails since references to (for example) fields on the card containing the handler script don't resolve properly. The handler is however also in a behavior, which has certainly been correctly associated with the target card.
>>> 
>>> Am I doing something wrong, or is this an LC limitation, or is it a bug?
>>> 
>>> Graham
>> 
> 
Dar also wrote:
> 
> There are two problems with that description.  
> 
> One is what Mark mentioned.  The default stack will change to the stack of the target object and the default card will be the current card of that the new default stack.
> 
> However, there is something else.  The word "message" should be replaced with "handler".  
> 
> That is 'this stack' here refers to the stack of the sender:
> send "doSomething x, the name of this stack" to card "uno" of stack "beta"
> 
> But here in card "uno" it refers to that of the target:
> 
> on doSomething x, y
> 	put the name of this stack
> end doSomething
> 
> Dar