Bridger,
The thing is a
card may have a handler in it that is triggered, that refers to an
object on
another card. Because it has been seperated from the rest of the
stack, it
can't find that object and it causes errors. Once it is inserted into
the
new stack it should stop causing errors, but until then I need to lock
the
messages to the stack holding the card so it doesn't trigger anything.
I
can't really predict what handlers will be triggered, or what the
errors are
going to be so I can't just intercept them beforehand. Any ideas
1. Isn't it possible to isolate the line in Stack 1's handler where
this occurs and lock/unlock messages before/after that line?
Eg:
on createStackForNetwork stack3CardId
....
....
lock messages
copy card id stack3CardId of stack "Stack 3" to stack "Stack 2"
unlock messages
...
...
end createStackForNetwork
2. I'm still having trouble understanding why you can't predict when
and what will happen if Stacks 1, 2, & 3 are your creations. Only a
limited number of messages might trigger Stack 3 card handlers when the
card is copied to Stack 2: newCard, preOpenCard, openCard, and
closeCard. If you step through the handler in the debugger with the
Message Watcher open, you should be able to determine the line(s) that
trigger the problem.
Rob Cozens
CCW, Serendipity Software Company
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
