The rub lies in the fact that Revolution (WHOOPS! Sorry RunRev (WHOOP! Sorry LiveCode!)) allows short references to objects. If you refer to "button 1", LiveCode resolves this internally to mean "button 1 of [the background the button belongs to if any of] the card I am currently looking at of the stack that card is in.
So when you call MouseUp for a button on another card, the card you are STILL IN is the one you are looking at, NOT the card the button is on which contains the mouseUp handler. By actually GOING to that card first (one method) "the card you are looking at" now means the one the button you are sending mouseUp to is on, because you just went there, and now the card and all it's objects are loaded into memory. Now something to consider when writing scripts in buttons or any kind of card object like fields and menus and such, is that the scripts in the objects should not do anything that refers to objects not on the current card. Some would disagree with me, but I think this is a good practice in order to keep your code readable. Instead, handlers like that should be in card, background or stack scripts because of the kinds of issues you encountered. For instance, if I have a script that modifies objects on each card, I would put that script in the stack script, because all the cards are in the stack. I could get the long names of all the cards of this stack, and then loop through each line to build the long names of all the objects I am referencing, but as noted above, it is often easier to lock the screen and then actually go to each card (as noted above). Also, I try to avoid doing any coding in buttons and fields and such that actually change anything. I call functions and commands in the card, background or stack scripts, depending on the scope of the command or function. It's nice to have your code modular, so that it is contained in each object that calls it, but practically it gets to be a real pain later on when you have LOTS of handlers in LOTS of objects. Keeping track of where it all is becomes unmanageable in a hurry. One more thing (and pardon my lengthy reply) but often people with past experience in Hypercard continue to use the method of having one card per bit of information to store their data. Just know that LiveCode is not really optimized for this, as many Hypercard importers have discovered. It's probably better to store your data in a custom property and design your cards as forms instead. Just my 2ยข Bob On Oct 20, 2010, at 9:47 AM, charles61 wrote: > > Robert, > > I understand your previous e-mail about using custom handlers. I have never > used this concept before. But I am not following you when you sent the > following: > > f one uses full reference in the called script (that is script in > btn b of cd y refers to itself as btn b of cd y) then going to that > card before running that script is not needed. > > While the script that Klaus posted works, I still want to fully understand > your comments above. Could you elaborate further? > > Charles Szasz > [email protected] > _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
