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
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to