Hello Dave, > Date: Wed, 14 Apr 2004 18:03:19 +0100 > From: David Burgun <[EMAIL PROTECTED]> > Subject: Re: Some Basic Misunderstandings/Problems with RunRev - aka > Help!
>>> Why doesn't the documentation say anything about this? > > I mean that if you look up the "save" command it makes no mention > that you can't save a stack if it's a Standalone. In fact I've found > the dictionary good for checking the syntax of a command/message but > absolutely useless for putting the command/message into context. ---------- ??? Here is a copy/paste _directly_ from the Dictionary: *** You cannot save to a standalone application�s file; standalones are read-only. *** ...Without trying to be pretentious, that seems fairly plain to me. I believe I understand what you want to do. One of the things I do is build ableware/adaptiveware stuff. These have a bunch of options and controls which need to be saved. A standalone contains the Rev/MC engine, which does _not_ allow saving to itself, which is common industry-wide. For this reason, most Rev developers use the Splash (Richard says to make a memory error dialog so you don't leave the user wondering what happened if the thing sucks up too much memory at startup...I tend to favor this approach myself) as the Main stack, i.e., it contains the engine, which, after initialization (globals, etc,) Consequently, your GUI should have been developed as a substack, initialized and opened by the Splash (which is really the Main stack with the engine). When you close, you save this substack from the Main stack. It will be saved with whatever changes you made to it. The question then becomes: How does your stack operate according to the settings? Way #1 My first suggestion if you have backup issues or want to otherwise ensure the safety of the settings, is to save values that relate to your controls in a text file as has already been suggested. This is the safest way, because it's easy to save, easy to back up anywhere, easy to recover, and can be read by other apps if your standalone takes a crap, or you want to change it and something goofs up. Way #2: You could simply have each routine that needs to know the status of a checkbox check to see if it's hilited via a path, on the fly. But that's slow, inefficient, and totally vulnerable. You'd need to backup the whole thing, GUI and all, or else, if it goes down, you lose everything. Way #3: If you feel you must save within the GUI, then save the status of the controls in both global variables and in the lines of a _hidden field_. When you change a control, put it's status value into a global variable as well as the designated line of the hidden field. This way, when the stack starts up, it reads the values from the hidden field into the globals in an initialization routine. Then all your routines need to do is operate off the status values in the globals. BTW, in the text file save scenario, it does essentially the same thing, except it's safer. I sincerely hope this helps and makes sense. Ken N. _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
