Unacceptable File Size Increase

[Blair Morrissey]

1. As I am sure will be obvious, I have had no formal study of  
scripting or coding. My first experience and only non-Rev experience  
is with Hypercard; however, my work using Rev has NOT involved the  
importation of any Hypercard stacks.
2. My problem using Rev is that given the jury-rigged ways neophytes  
do things, my stack is getting mysteriously bigger. It is now 90 MB.
3. My mainstack has many mutually similar substacks. It also has  
several different utility substacks.  In the mainstack, I have a card  
(let's call it card X) which I use as the BASIS card ( I do not want  
to use the word templatecard as I do not understand how such things  
work in Rev) for the cards in the many mutually similar substacks.  
That is, I want the cards in the relevant substacks to be identical  
to card X in the mainstack.
4. As I revise and augment card X in the mainstack, I want to be able  
to update the mutually similar cards in the substacks preserving the  
content of their fields and their handler calls. On card X,  there is  
a field which contains a version number of the then current design of  
card X. Probably reinventing the wheel with a hexangonal one, 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. The handler then proceeds in that substack to go  
to each card, paste a copy of that substack's new version of X near  
each existing card, transfer the data from the existing card to the  
one just pasted (I generally do not use ID numbers of objects), and  
then delete the old card. It does this for all cards in the substack  
and then proceeds to the next similar substack.
5. In a sense the above works well. I use this mainstack and its  
substacks daily in my non-computer related job.
6. BUT now each time I go thru the above process (step 4), the  
overall file size increases unacceptably.
7. Could it be that the records Rev keeps of deleted object IDs is  
causing the problem. If so can I delete that file of IDs. Only in a  
few places (that could easily be changed) do my handlers refer to  
objects by their IDs.
8. Should I learn about non-Rev databases and keep my data outside of  
Rev?
9. Should I keep the data in the substacks in a separate Rev  
mainstack and set of substacks whose appearance and functionality is  
not important and then somehow (I have done this once or twice) bring  
this data in when a user requests a card?
10. I hope there is a much simpler way to do step 4. Is there  
anything like:  set the templatecard to (the revised) card X. Let's  
call this templatecard X. The handler would then go to each relevant  
card in a substack and set that card to the new templatecard X  
maintaining the contents of fields where similarly named fields exist  
in the new card and perhaps asking for permission to continue if  
there is a non-empty field with a name on an obsolete card that does  
not have a similarly named field on templatecard X.
11. Virtually all handlers are in the mainstack script.
12. THANKS FOR READING THIS AND SORRY FOR ITS LENGTH.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution