Unacceptable File Size Increase

[Bill Marriott]

Blair,

I am not sure I understand completely what you're doing with your stack, but 
two thing pop out at me.

The first is: Have you considered using a database like FileMaker Pro to 
manage the information in your system? This will impose some structure and 
order on what you're doing. It will separate the information you're storing 
from the presentation. (So you don't have to go in and "manually" update the 
design of all the substacks, for example.) You will still be able to script 
things, but you'll find the need for scripting diminished greatly. A free, 
fully-functional 30-day trial is available from 
http://www.filemakertrial.com

The second is: Have you looked at groups that behave like "backgrounds?" 
These would let you share one design across multiple cards. When you updated 
the appearance of a group on one card, it would also update the appearance 
on other cards. Though, I haven't tried to use them across substacks.

As I mentioned in another post, Rev should automatically compress a stack 
when you choose the Save command from the File menu (but it won't went you 
issue a save command from a script). So try that at least once. If the file 
size remains large, then it would seem that you are leaving a lot of stuff 
around in the stack, perhaps hidden, that is making it bloat up. Like 
images/bitmaps. Or perhaps you are repeating the same image on every card? 
Again, backgrounds would probably eliminate this problem.

- Bill

p.s.: what make the post hard to read wasn't so much the length but the lack 
of space between paragraphs :)


"Blair Morrissey" <blairmorrissey at mac.com> wrote in 
message news:B1825729-9708-4EDF-9EFB-724AC2FEC158 at mac.com...
>
> 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.
>
> 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.