Some Basic Misunderstandings/Problems with RunRev - aka Help!

[Ken Norris]

Hello Dave,

> Date: Wed, 14 Apr 2004 18:03:19 +0100
> From: David Burgun <dburgun at dsl.pipex.com>
> 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.