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
On Jun 2, 2012, at 4:28 PM, 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 Scott
dba
Dar Scott Consulting
8637 Horacio Place NE
Albuquerque, NM 87111
Lab, home, office phone: +1 505 299 9497
For Skype and fax, please contact.
d...@swcp.com
Computer programming and tinkering,
usually in supporting those developing in
LiveCode--typically by making LiveCode
controls, libraries and externals, and
sometimes by writing associated
microcontroller firmware.
---------------------------
_______________________________________________
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
