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