Hi Jeanne,
At 1:21 PM -0700 4/3/05, Dan Shafer wrote:Copying a background from one card to another *duplcates* the background so that changes made to one of them will not be reflected in the copy. Placing a background seems to me to at least imply that the author intends for the background to be shared so that changes to the background made from any card will be reflected in all other cards on which the background appears. To make that happen, the group must be set to behave as a background.
Actually, this isn't so - a group can be shared without having its backgroundBehavior property set to true. Shared groups worked fine even before the backgroundBehavior property was added to the language. What backgroundBehavior does is cause shared groups to be automatically placed on new cards, as well as tweaking the message path for the group so it matches HyperCard's behavior more closely.
EXACTLY! That's what i meant...
:-)
(My only excuse for not documenting that "place" turns on backgroundBehavior
AHA!!!! OK, once i know, it is not harmful anymore :-)
is that no one told me about the change, and I didn't stumble across it on my own when the property was added. If I had been told about it, I would have argued that it was a bug, not a feature. Commands shouldn't spew side effects like that, even if they're documented. As it is, apparently if you want a shared group whose backgroundBehavior property is false, you need to remember to reset the property after every time you place the group on a card.)
But "set the backgroundbehaviour of grp xyz to false" does NOT work after placing that group onto a card,
and that might be a bug?
In my case i want to loop though a textfile, create cards and place DIFFERENT bgs (with NO bgbeh.)
onto the cards according to the current "record"...
The whole situation with backgroundBehavior is confusing.
Yo, took me quite a long time to understand, but now is it pretty logical to me ;-)
It was added in order to better emulate HyperCard backgrounds, which it does, but there were collateral changes (for example, changes to what "the backgroundNames" means) that resulted in, IMHO, a mess.
--
jeanne a. e. devoto ~ [EMAIL PROTECTED]
http://www.jaedworks.com
Regards
Klaus Major [EMAIL PROTECTED] http://www.major-k.de
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
