Bill Vlahos asks:
> Programs created with Revolution contain both the runtime build and any
> user supplied data in the same standalone file. Let's say I write and
> distribute a program with the 1.0 version and future versions of
> Revolution come out which offer new features which I want to add as
> upgrades to my already distributed programs. After I buy the newer
> version of Revolution, how would I get programs already in users' hands
> upgraded with the new features?
>
> This same question would apply to sidegrades. Let's say, for example,
> that a Windows users gets my program and wisely wants to switch to
> running it on a Macintosh (or any other platform).
>
> Would I need to provide an export/import mechanism before I distribute
> the program or would there be an "updater program" to run on existing
> distributed versions of my app?
In addition to the benfits of separating the interface from the data that
Geoff pointed out, there's another aspect to this: On Widows and UNIX,
running executables cannot ordinarily write to themselves. For consistency,
it's my understanding that standalones made with any of the Revolution
engines follow the same rule: if it's a standalone, it's read-only.
While this may seem like extra work for folks coming from HyperCard and
SuperCard (I used to gripe about it myself in the early days of my MetaCard
adoption), in the long run you -- and your users -- will be happier with a
new archicture that separates UI from data.
As you've noted, it makes updates so much easier. But I've also found that
it makes development and maintenance much easier as well. I usually write
accessor handlers to get and put data, often storing the data in custom
properties of a separate stack. But if you're late in the development stage
and pretty much committed to having the data stored in the UI fields, you
could probably just clone the stacks that contain user data into a separate
stack file outside of the standalone, and then just open that stack file
during startup.
Here's a handy handler for multi-file installations -- put this in the stack
script of the standalone or in a backscript so it'll be available throughout
your project to easily locate files in the same directory as your
standalone, even during development (before it's a standalone):
function AppPath
local tPath
put the filename of stack "MyStandaloneStack" into tPath
set the itemDel to "/"
delete last item of tPath
return tPath
end AppPath
You can use it to open a document stack file in the same folder like this:
open stack (AppPath()&"MyDocument.rev")
One more consideration with separate files: If your installation will allow
users to launch the app by double-clicking a document, you'll want to come
up with your own three-letter file name extension, just as you would
register a unique creator code with Apple for Mac OS. This will help
prevent cases where double-clicking your document stack file launches some
other app.
Yes, one more step, but since file name extensions will eventually replace
creator codes with OS X, it's something we need to get used to for any
platform.
--
Richard Gaskin
Fourth World Media Corporation
Multimedia Design and Development for Mac, Windows, UNIX, and the Web
_____________________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
Tel: 323-225-3717 AIM: FourthWorldInc Fax: 323-225-0716
