Saving data in a stack ­STANDALONE

[Richard Gaskin]

John Ridge wrote:
> As a complete beginner with Revolution I¹ve found it very hard to get a grip
> on this. It¹s a big stumbling block for those used to Hypercard, where the
> IDE was taken for granted, and the concept of a standalone was unfamiliar.
> But the ability to deliver standalones cross-platform is a major attraction
> of Revolution ­ so it¹s disappointing that such a key feature as how to save
> user changes to a stack is hard to grasp.
> 
> I can understand that a standalone is an application, and as such shouldn¹t
> modify itself ­ i.e. the user can¹t save any changes within the application.
> No problem ­ write it out to a file, and read it back in on startup. But
> with structured data such as an Address Book you want to save the data as a
> stack ­ that¹s the whole point!
> 
> The answer given in the documentation is to set up a "dummy" stack as the
> mainstack, then do the work in a substack which is not itself compiled into
> a standalone, but left as a Revolution file (.rev). I simply couldn¹t get
> this to work, until I came across the answer in the lists.runrev archive ­
> go to the Standalone Settings item on the File menu - select the "Stacks"
> tab - click the box to "Move substacks into individual stackfiles".

I can symphathize with the learning curve effort, but IMO the biggest 
conceptual hurdle isn't inherent in the process but rather introduced in 
the standalone builder which doesn't adequately label optional advanced 
features as such.

All the engine requires to make a standalone is a stack and a little 
information about the resulting standalone (target file name, Windows 
info, Mac Finder info).  Everything else is purely optional, and by not 
separating those from the essentials the standalone builder gives the 
impression that the task is more complex than it really is.

Many people enjoy the Rev option of modifying the stack structure at 
build time (moving substacks in and out of separate stack files), but 
I'm a big fan of WYGIWYG:  "What you got is what you get". :)

For myself I find that minimizing the differences between development 
and runtime helps minimize errors, nearly eliminating the range of 
possible issues that can arise from differences between the two 
environments.

If you were to use this approach your development setup might look like 
this:

     ----------------------------              --------------------
     |"splash screen" stack file| -- opens --> |Main UI stack file|
     ----------------------------              --------------------

By "opens" I simply mean that the "splash screen" stack opens the main 
UI stack in its openStack handler.

When you build you get simply:

     ---------------------------               --------------------
     | standalone executable   |  -- opens --> |Main UI stack file|
     ---------------------------               --------------------

No fuss, no muss, no relying on hidden processes altering your stack 
structure at build time, nothing more than the simplicity of working in 
and running the same setup.

If using the advanced stack-morphing options has been confusing, you 
might consider this simpler WYGIWYG approach.

--
  Richard Gaskin
  Fourth World Media Corporation
  __________________________________________________
  Rev tools and more: http://www.fourthworld.com/rev