Pamela nightmare over: post-mortem

Richard Gaskin ambassador at fourthworld.com
Mon Aug 2 14:14:58 EDT 2004


Hello Pam -

> Richard Gaskin asked about images.  There is a background image in the
> mainstack that distributes to the substacks.  No other images of any
> kind in the corrupted stack.  I agree that Photoshop provides the best
> images for Revolution, and I always use that, rendering usually jpg
> but sometimes png images for logos or backgrounds. All other images
> displayed via this application come from the server.

What I had asked was:

     "Just a wild guess:  are there any image objects there?
      If so, what happens if you remove only those?"

I looked at your stack file.  None of the substacks themselves nor their
cards appear to be corrupted.  I removed the three images from the
substack "MONGOL_EDIT" and it opened fine on Windows.

It may be that only one of the images has bad data, but I didn't have
time to do the trial-and-error of deleting one at a time until I found
the culprit.

I'm at a loss to determine why the images would work well on Mac OS and
not Win, but the exercise was instructive in serving as a reminder about
the nature of corruption and how understanding that can help diagnose
problems.


If you come from a HyperCard, SuperCard, or FileMaker background it's
understandable that a wide variety of unexpected behaviors will be
viewed as file corruption.  But the notorious 5454 error that plagued
all but the most dilligent HyperCard users (that would be Paul Looney
<g>) is a card-level corruption that is almost entirely unknown with Rev.

In Rev, in the very rare cases that something is corrupted in my
experience it's limited to a single control rather than the card or
stack record.  In working with the engine for more than seven years I've
seen only one such case many years ago, and while I've heard of others
their descriptions do not appear consistent with actual corruption.  In
all but one case I've seen firsthand things that were reported as 
corruption turned out not to be (with the one exception from seven years 
ago being an image control).

I've written about corruption before, and to avoid sounding like a
broken record I'll just provide links to that background discussion if
it's of interest:
<http://lists.runrev.com/pipermail/use-revolution/2003-June/017928.html>
<http://lists.runrev.com/pipermail/use-revolution/2002-December/010842.html>
<http://lists.runrev.com/pipermail/use-revolution/2002-December/010776.html>

The most relevant point is the one Scott Raney closes with in the last
of those posts

     If you've got something that you can reproduce, by all means
     send in a bug report so that we can make it even rarer ;-)

It would be helpful to send a note to support at runrev.com with a note on
how to get the stackfile.  It might also be very helpful if you have the
original image files used in that stack, so they can be compared with
the image data in the imported image objects.


How did I know the images were the culprit?

Like I said, it was just a guess.  But in the only case of actual
corruption I've ever seen firsthand the cause turned out to be an
imported image object, so it seemed worth trying those first.

I can't stress enough how useful it can be to try to forget the scarring
experiences of stack- or card-level corruption you may have encountered
with other tools when diagnosing problems encountered with Rev.

When something is corrupted the remedy usually involves deleting the
offending object and rebuilding it.  If you decide it's a card or a
stack or the entire stack file before you really know if that's the
case, you can spend a great deal of time rebuilding objects that don't
need to be rebuilt.  If the engine can open the file, any problem can 
probably be fixed with relative ease.

In seven years with the engine, your image objects are only the second
instance of corruption I've seen.  And the remedy was far simpler than
what's normally needed for correcting corruption issues in HyperCard.

The only other case of corruption I've seen was also with imported image
objects, but this is understandable as imported image objects are
complex creatures in which most of the data the engine's dealing with
was created by some other app.  I've never seen a corrupted object which
was created entirely by the engine itself; not to say it can't happen,
but it's rare enough that I don't think about it.

And before you get the impression that imported images are somehow
problematic, consider the odds:  Think of the number of Rev users and
the number of images they import into stacks every year, and remember
that the engine's been around since 1992 with very few verifiable cases
of corruption.

Since 1997 I've only seen two such cases, so I have a high degree of
confidence that corruption does not occur with 99.9999% of imported
image objects, and 99.999999999999999% all other objects. :)

Summary on corruption:

1. Most of the time when the engine reports corruption it's a case of an
interrupted save, and you'll find an intact copy of your stack with the
same name preceeded by "~" waiting for you in the same folder as the
"short saved" stack.

2. If the engine reports corruption and there's no such backup stack, 
see if there's a way to open the stack file, such as on a different
platform.  Look at imported images first, and with some trial and error
you can usually find the culprit in short order.

3. If you see a behavior that looks like it might be corruption but the 
engine doesn't report it as corruption it probably isn't corruption, so 
looking elsewhere at scripts and/or IDE bugs may the best way to look 
for the root cause.

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




More information about the use-livecode mailing list