Restraining the pencil in Rev

[Robert Brenstein]

On 21/09/08 at 08:30 -0700 Joe Lewis Wilkins apparently wrote:
>I guess this is my day for confusion. (smile) I'm not using a player 
>for any of this.
>
>I have a fairly simple stack consisting of some 50 cards, each of 
>which has one or more images and some fields and/or buttons. Using 
>the bucket tool, a user may color inside the lines of the images as 
>they see fit - often pretty complex. Once colored, they may print 
>portions of the cards that I designate in the print routine; but, 
>once the stack is closed, all of these colorations disappear. I 
>would like for them to be able to Save a copy of the colorized stack 
>under a new name, as a document?, from the standalone. Then, as you 
>have indicated it can, have that copy open as a document "of" the 
>standalone when double clicked upon. So far, I've used:

Joe,

I believe your confusion arises from not realizing that in order to 
accomplish what you want and others suggest, you need to change the 
paradigm, well, design of your program. It appears, you keep the code 
(program scripts) and the data (images, fields, and whatever) in the 
same stack file. When you use this in IDE, all is fine. However, when 
you create a standalone using this stack as the program, your 
standalone is both the program and the data file. Since it can't 
modify itself when used, you run into a problem. To get out of this 
concodrum, you need to separate the program from the data. You can 
use a few approaches:

Simplest to implement is to keep your program pretty much as it is 
but add a launcher stack which can display only a splash and then 
call your stack. When creating a standalone, you create it using only 
the splash stack, keeping your work-horse stack as a stack. In this 
mode, there is no problem to save the changes. What can be 
problematic is handling the upgrades if your program is being 
distributed to users.

Note that if you don't care about branding your program, you can use 
the StackRunner instead of your own splash-stack-standalone.

A variation of this is to use your splash stack as a library, that is 
move as much of coding to it as possible, with only minimal scripts 
in the data stack, which all call your library functions to do the 
actual work. This way, your data stacks may require none or little 
changes when the program changes.

On the other extreme is to keep the data, that is whatever users 
enters, changes, in a separate file, possibly a stack but this is not 
required, which has no programming code whatsoever. Your program 
simply uses it as a repository of user data, recalling it as needed 
in the display/work program. This approach allows you to have a true 
document-like behaviour, that is users can keep and save the 
data-stack files anywhere and you can even go as far as to have them 
open by double-clicking.

Robert