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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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. _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
