Richard Gaskin, An AutoSave Plugin?

Richard Gaskin ambassador at
Wed Dec 10 01:11:16 EST 2003

SimPLsol at wrote:

> I do feel compelled to defend "corruption-prone" HyperCard a bit.

It wasn't meant as a dig against HyperCard, just noting the tradeoffs
inherent in each architectural choice.  Completely aside from any subjective
views of HyperCard one way or another, page-from-disk systems simply require
a more complex set of read and write routines, and no complixity comes
without risk.  FileMaker is quite up front about the tradeoff:  it has a
"Recover" item in the File menu which repairs corrupted files.

Paging from disk does not mean that everyone will always experience
corruption.  But it does mean that the risk is significantly higher, and a
broad sampling of user experiences across many applications seems to bear
that out.  Like yourself, those who dilligently anticipate corruption in
such systems can minimize their risks through regular compaction and other
tidy habits.  But unfortunately the less dilligent report a different

> We sell a HyperCard-based business system which consists of 43 stacks.
> The most heavily used is Orders/Quotes. On any business day there are
> over 1,000 people writing orders with it. In a typical year (and we've
> been at it for 16 years) we had 6 corruptions worldwide (not bad
> considering the level of activity, the working environments, the
> flexibility of the system, and the lack of any formal IT departments
> at most customers' businesses). After discovering and avoiding the
> HyperCard problem with null sets that caused 5454 errors, the number of
> corruptions annually has fallen to 3. I will be extremely pleased if
> Revolution does as well.

Thus far Rev has a good a good record:  in the last several years I've seen
very few corruption cases (I had one five years ago and Alex had one more
recently).  Although I don't have hard numbers, I would think it's realistic
to guess the percentage of similarly affected HC users would be at least two
orders of magnitude greater.

Again, this is not a dis about HyperCard, or even to suggest that
page-from-disk systems are something that should never be used.  But the
choice is not a light one, and does not come without risks.

When HyperCard was born RAM was expensive, so a disk-intensive solution was
the only practical choice at the time.  The Rev engine was born on Unix,
where memory is generally assumed to be plentiful and swap space efficient.
Very different worlds giving rise to very different solutions.  Neither is
necessarily bad, but it's useful for those coming from HC to understand the

Rev puts the user in control with regard to saving because it can.
Restricted to the memory available on the Mac Plus, HyperCard just didn't
have that luxury (it's worth noting that most other Apple apps before and
since leave the user in control of saving).  In Rev you can build any
variety of auto-save systems to suit your needs.  In HyperCard "Revert to
Saved" was not possible;

  The moving cursor clicks; and, having clcked,
  moves on: nor all your piety nor wit
  shall lure it back to cancel half a line,
  nor all your tears wash out a byte of it

   (apologies to Omar Khayyam)

While a habit reliance on auto-saving behavior is part of the unlearning
curve for HyperCard and SuperCard users (and easily accomodated with a brief
script), for those who cut their teeth elsewhere Rev's adherence to the more
traditional apprach of leaving the user in control is welcome.

> Meanwhile I look forward to seeing you at the seminar and learning
> more about plugins. Can one set the front script from a plugin?

The true beauty of plugins is their simplicity: they're just stackfiles, the
Plugins menu just a convenient way to open those stacks. So yes, all of
Transcript is available to a plugin, including control of front- and

In fact, keeping in mind that the development environment allows unlimited
frontscripts, backscripts, and "start using" libraries, here's a technique I
use for things like my Property Sheet plugin ("4W Props" in RevNet):

The palette must trap the selectedObjectChanged message in order to know
when to update its display.  So it inserts a frontScript when it opens which
catches that message, updates itself, and passes it so other stacks can also
update themselves.   On closeStack it cleans up after itself by removing the

By using their own front- and backscripts, plugins can be entirely
self-contained, modular lil' nuggets o' usefulness. :)

 Richard Gaskin 
 Fourth World Media Corporation
 Ambassador at
 Tel: 323-225-3717                       AIM: FourthWorldInc

More information about the Use-livecode mailing list