Saving changes

[Richard Gaskin]

John Tenny wrote:

> The following from a S-Card user re changes in a distributed stack. Is
> it really a "laborious" task to have cards save the data entered on
> them in a distributed stack or is there some nice checkbox to click
> somewhere?
> --------
> "If I create a Rev stack and make a standalone of it, put it on another
> machine. It doesn't save changes. For example when I test out your
> Observation Tools stack. I go to maybe the positive/negative statements
> cards. Play with it a bit. Close the stack. Open it again and all the
> data on the pos/neg card is lost. They must be saved in a separate
> document because that's the way Windows does it. That's fine, but the
> last I checked, Rev didn't automate that process. I had to go in and
> laboriously script which fields I wanted changes saved from and where
> those changes were saved. That's something Rev doesn't point out in it
> ads. This doesn't happen, of course, in SuperCard. Changes are
> automatically saved. No muss, no fuss."
> =======

Did I miss that on this list?

It's neither a checkbox nor necessarily laborious.  As with porting from
HyperCard to SuperCard or between any two xTalks, some changes are likely
needed to account for differences in each program.  After all, if they were
exactly the same there would be only one. ;)

Here, what you've encountered characterizes most of the distictions between
SuperCard and Rev:  SuperCard only runs on Mac OS while Rev runs on all
major operating systems.

Mac OS allows an application to write to itself but most other operating
systems don't.  So Mac/SuperCard users have a unique disadvantage when
porting to multi-platform Rev as they have been acclimated to a habit that
is not possible elsewhere, requiring a little re-thinking of data storage to
get past it.

It's worth noting that even though Mac OS allows an app to write for itself,
Apple recommends storing user data outside of the app in a user folder, so
the following discussion would also benefit SC users looking to modernize
their apps:

In its simplest form, all you have to do is save the substack holding the
data (what would be a "window" in SC) to a separate file outside the stack
that is to be the standalone.  Just have the standalone open that stack when
it starts and from that point on you can address it by its short name -- you
can even use the SC syntax if you prefer ("window" is often accepted as a
synonym for "stack" in Transcript specifically for the benefit of SuperCard
users), e.g.:

   get the rect of window "MyStackName"

Better still would be to go the extra mile to install the data stack to the
user's Preferences or Documents folder on Mac and the My Documents folder on
Windows (the paths to these can be obtained with the built-in
specialFolderPath function).

One could go a step further, depending on the nature of the app, by
completely separating the data from the interface.  There is generally some
value in separating code, data, and UI, as it helps keep clear dividing
lines between each, theoretically inspiring more modular and robust systems.
But since so many legacy projects depend on keeping the data stored in the
same stack it's displayed in, the expense of reworking it to store the data
in user props, text files, or a database is often more trouble than it's
worth.  Such a migration can indeed be laborious, but is not necessary for
most ports; simply moving the data stack outside of the standalone is all
that's truly needed.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge: Publish any database on any Web site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc