Unacceptable File Size Increase

[J. Landman Gay]

Blair Morrissey wrote:

> I have handlers 
> that when called, get the current version number on card X in the 
> mainstack and then go to each relevant substack which has a copy (or 
> clone, I can't remember) of a now obsolete version of card X. That is, 
> each relevant substack has its version of card X. (I have forgotten why. 
> Most of the scripting work was done two years ago.) If the script finds 
> that a substack's version of card X is now obsolete (indicated by a 
> lower version number), the script deletes the substack's now obsolete 
> version of card X and pastes the current card X into the substack.

I think this may be the problem. Every time you paste a card, you are 
duplicating every object on it. A stack with 800 cards will have 800 
copies of every button, field, etc. on its card. That can increase size 
very quickly.

Instead of pasting, you should make a single background group in each 
substack that has all the elements and controls in it. When you need to 
transfer a card, don't copy/paste it. Instead, gather all the data into 
variables, make a new card in the substack (which works like HyperCard 
did, and does not duplicate the objects, it just uses existing 
background objects) and then populate the fields with the correct info 
that has been stored in the variables. You do not even need to delete an 
obsolete card, you can just overwrite the field contents with new 
information.

You should see a substantial decrease in size if you do this. However, 
to get the most benefit, you should remove all the existing cards (which 
have many duplicate objects currently) and replace them with cards that 
share a background. If you don't, your stack size will remain large 
although the creation of any new cards won't add much more to it.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com