Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!apple!well!jdevoto
From: jdevoto@well.UUCP (Jeanne DeVoto)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Losing background on copying card
Message-ID: <7861@well.UUCP>
Date: 8 Dec 88 03:04:07 GMT
References: <1255@client1.dciem.dnd.ca>
Reply-To: jdevoto@well.UUCP (Jeanne DeVoto)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 29

In article <1255@client1.dciem.dnd.ca> mmt@zorac.dciem.dnd.ca (Martin Taylor) writes:
>
>I have a stack with one major background and 2 minor ones, one of
>which occurs on cards distributed through the stack, the other only
>on cards at the end of the stack.  I have built this largely by copying
>cards and amending the copy.  Now, I find that if I copy a card from the
>major background, and paste the copy just before the final set, the
>resulting card belongs to a background for which the pasted card is the
>only representative.  The new background has all the properties of the
>old, including name and script, but this does not help when I want to
>show or hide buttons and fields for the major set of cards.  Is this
>a known bug?  What kind of work-around is there?


The times when I've seen this problem (pasted card having a new background),
it's been due to a temporary alteration in a background object. One example:
suppose you have a background button that copies a card and pastes it some-
where else in the stack, and suppose this button has autoHilite turned on.
When you click on the button, its hilite property is true. This is A CHANGE
IN THE BACKGROUND as far as HyperCard is concerned, despite the fact that
the hiliting only lasts as long as you are clicking the button. If your
script copies the card while the button is hilited, then goes to paste in
the card, it's pasting in a card with a (slightly) different background, so
HyperCard assumes it should create a new background for the pasted card.

Hope this is helpful.....

jeanne a. e. devoto
jdevoto@well.UUCP