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
_______________________________________________
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
