Finding objects where the handler is [solved]

[ittarter]

Hello,

So the way LC works, if a handler is triggered by a handler on a different stack, the second handler looks for objects on the stack of the original handler.

example:

Code: Select all

on mouseup --Card A of Stack A
   send "myHandler" to stack "AnotherStack"
end mouseup

on myHandler --Card A of Stack B
   put "hello" into fld "test"
end myHandler

Result: fld "test" isn't found, because it's on Stack B, not Stack A.

How can I tell Card A of Stack B to look at its own objects instead of the objects of Stack A?
Obviously I can use

Code: Select all

put "hello" into fld "test" of card A of Stack B

but I have hundreds of fields and I would rather keep my code tidier than that.

Putting

Code: Select all

go card A of Stack B

or

Code: Select all

open card A of Stack B

doesn't change anything, unfortunately.

Any ideas?

[Klaus]

You could set "the defaultstack" first in your handler:

Code: Select all

on myHandler --Card A of Stack B
   set the defaultstack to "B"
   put "hello" into fld "test"
end myHandler

Is a bit of work, but if you are "sending" lots of things, it is worth the effort.

[dunbarx]

This might run into trouble if there were three or more stacks worth of "sending. You might, of course, log the stacks as you go.

I run into something like this all the time with subStacks on a current project . My issue is that the mainstack name changes constantly, though its substacks never do. So I simply:

Code: Select all

get fld 1 of the mainStack of this stack
  or
go stack the mainstack of this stack

That sort of thing. in this way each subStack knows who its "parent" is, regardless of any property changes of that parent. Just a variation on a theme.

Craig Newman

[ittarter]

You could set "the defaultstack" first in your handler...

I think this will work well. Thanks, Klaus.

in this way each subStack knows who its "parent" is, regardless of any property changes of that parent. Just a variation on a theme.

Good to know for the future!

[jacque]

This situation is what the "call" command is for. Try that instead of "send". (Not tested but theoretically should work.)