On Aug 28, 2011, at 4:16 AM, Peter M. Brigham, MD wrote: > From the user guide: > > "If a stack's dynamicPaths property is set to true, message handlers in that > stack use HyperCard's dynamic path behavior: if a handler uses the go or find > command to go to a card other than the original card, that destination card's > message path > is inserted into the message path as long as the handler is on that card. The > dynamicPaths property is provided for compatibility with imported HyperCard > stacks, > and is normally set to false, but you may encounter this behavior when > working with a > stack that was originally created in HyperCard." > -- Peter
Thankya Peter, you may be onto something here. I found at least one stack where the dynamicPaths is set to "false." That could cause erratic behavior, I suppose. As I read the dictionary carefully, it appears that theDynamicPaths refers only to the "go" and "find" commands. It doesn't say anything about handlers being sent along the normal message path. (This thread is getting complicated. I'm going to start another thread about the dynamicPaths.) In my case, "go" and "find" seem to be working fine. The way a handler gets sent along the normal message path to another stack seems to have changed. > From the dictionary: "Use the send command to override the normal message > path, or to delay a command until a specified time." My script only uses the normal message path. >From the dictionary: > "When the send command is used the stack containing the target handler > temporarily becomes the defaultStack." Hmmm... In my case, the old script, which stopped working, did not use the "send" command. The handler sat by itself on a single line of the script. I had the impression that this is the normal way of sending a handler along the normal message path, as long as the handler is only one word. Has that changed? The dictionary entry seems to suggest that using "send" is not necessary and might slow down a script. >From the dictionary: > Note: Using the sendcommand is slower than directly executing the commands > using the normal message path. For best efficiency, use the sendcommand only > when you want to delay the message or when the handler you want to execute is > not in the message path. Despite various sensible suggestions, it still seems possible that LC 4.6.x has slightly altered the way messages get sent along the normal message path. Perhaps deliberately, perhaps unwittingly. If that's true, I suppose other users will experience some problems. Every complex application has inexplicable anomalies. Maybe I've run into one. On the other hand, for every actual inexplicable anomaly, there are 1000 instances of user error. I'll change the script back to the old way, make sure it still doesn't work and trace it precisely. I'll report back if I find anything interesting. Cheers, Tim _______________________________________________ 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
