pkc wrote:
Hi Richard, thanks for that terrific essay. In principle I understand what you mean. How can a person tell if an "image object" is actually corrupting the stack? I never got any corruption messages from Revolution, and never even thought of corruption until Ken found it. Revolution happily ran the stack in the IDE, built both the OS X and Windows apps without comment, and the OS X application runs fine. The only hint of trouble came when the Windows app had reached it destination and couldn't be opened. I wonder if there is any way to get a hint of impending trouble during the compilation or during the build?
Did you run the stackfile in the Win IDE? When a standalone exhibits problems not evident in the Mac IDE, that's sometimes useful.
As for honing in on a corrupted object, first thing is to forget about corruption until the engine tells you a stack is corrupted. ;) Only after you run it in the IDE and it reports that it's corrupted is it worth going down that tedious road; in most other cases it's just a red herring that'll eat your time but not help you identify the actual cause of an issue.
But if the engine says a stack is corrupted, first check in the directory where the stack is located for a "`" copy (i.e., if your stack file is named "MyStack.rev" you'll likely see a stack named "~MyStack.rev"). This is a backup, which the engine makes automatically when you execute a save command. In 99% of cases where a stack is opened and the IDE reports that it's corrupted you'll find the automatic backup waiting for you, so you just toss the bad copy, remove the "~", and you're back in business with everything up to your last successful save.
In the very rare case where the engine will report that a file is corrupted and no "~" backup is available, the trick to finding the object giving you the trouble is like any other good problem solving: bisect the range of possibilities until you find it.
This assumes, of course, that you're able to open the file on at least one system. But if you can I would do this:
- Make a copy of the file. - Delete half of the substacks. - Try to open the file on the platform where the trouble was last reported.
If no error is reported then you know the offending object was in one of the deleted substacks. If an error is reported then you know it's in one of the remaining substacks.
So then make another copy of the original file and try it again: delete half of the suspect substacks. Repeat this until you get down to the one containing the object which is causing the error.
Once you find the troublesome stack, the first thing I do is try deleting all of the image objects there. If there is no problem then I can rule out image objects and focus on others. If the problem goes away without the image objects then I've verified my hunch, and can go back to a fresh copy and delete just half of the image objects, and so on, until I get the one causing the issue.
Once the offending object is found -- and this is the most important step -- send the stack file to [EMAIL PROTECTED] with a report letting them know what you've found and what they'll need to do to see the error. If you have the original image file that can also be very helpful, as the problem may be with something related to importing it or something in the image data itself, and having the original source image file will help them make that determination.
Fortunately this sort of thing is very, very rare. If your experience is like mine you'll go another seven years without ever seeing another corrupted object. :)
-- 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
