Stand-Alone Sorrow

[Marian Petrides]

The cryptic error message is vaguely reminiscent of the problem Pamela  
Crossley was having a couple of weeks ago.  In that case the problem  
turned out to be a corrupted substack. Others had, I believe, reported  
problems with image corruption causing bizarre errors.

I am appending Pamela's synopsis of her problem and some information  
Richard Gaskin summarized concerning corruption, especially image  
corruption, in the hope that it may help track down your problem.

NOTE:  I don't make a habit of repeating large portions of other  
people's posts, but in this case these both seemed to be valuable  
enough summaries that I saved them to disk and thought I ought to share  
them.  Sorry for the length of this post, especially if it doesn't  
help.

Marian
-----
Pamela's summary:

To review, the problem was:  An application built in OSX that built and  
ran without any problems in OSX could not under any circumstances be  
transferred to and run by a Windows machine.  Invariably, the resulting  
error was "0,0".  The fix was:  Ken Ray used MetaCard to identify a  
corrupt substack, I rewrote it, rebuilt for WIndows, distributed it as  
an .exe file (no zipping, in this case), and it worked.  The successful  
build happened to be in Revolution 2.2.1, which I had freshly  
reinstalled after searching hundreds of archives looking for the  
licence number.

Sounds simple, but it is worth remembering that before the application  
of MetaCard (as Andre foresaw) to this problem, there was absolutely no  
clue to where the problem lay.  In the end, we found out only where the  
problem lay, not exactly what it was.  That was enough to fix it, but I  
still have some questions.

First, I can say this from my experience of rewriting the stack:

As it happened the corrupted stack was one of the oldest in the  
application, and had certainly been present in very much its current  
form from the earliest builds (the ones that went across to Windows  
with no problems). In one of the scripts I found a stray "the" in an  
instruction.  I'm not assuming this was the problem, since I would have  
no way of understanding exactly how a "the" can cause disaster.  
Normally, that is the kind or error that the script editor seems to  
pick up as soon as the instructions are applied.  Now, it is possible  
to save the script anyway (and with a lot of windows open that can  
happen by accident anyway), so if this the source of evil, I should  
report that it was found.

Questions about that.  Why would OSX happily work around such as error?  
  Is this a deprecation issue? If so, my feature request for Revolution  
4.x or 5.x would be that it flag ambiguous items according to the  
standards of the least-likely-to-deprecate system (which I am guessing,  
in this case, is Windows).

Second, I found MANY scripts in this stack (and probably in others)  
afflicted by a pesky problem that has before this seemed to me to be  
merely an annoyance.  A lot of my scripts insert strange empty space  
between the last instruction and the bottom of the window.  In a very  
small number of cases, I have found for a long time that the script  
editor reports a compiling error when these strange spaces are present,  
and then compiles happily when I remove the space.  But removing the  
space is not usually final.  Some script windows keep putting the  
mystery space whenever the script is opened.  I sometimes just copy the  
script into a text editor, and delete the old script entirely, review  
it for errors (there are usually none), paste it back in a new window,  
apply immediately, close immediately, and save. These wrestling matches  
are sometimes annoying, but I've always been able to work around them  
and in any case the script editor seems to report what it sees as an  
error immediately.

Questions about that:  What is with the empty space misbehavior in the  
first place?  Is it dangerous? Can it corrupt a stack file? Is this  
also a deprecation issue (sort of, in reverse)?

I found nothing else in the visible stack instructions that seemed in  
any way possible to connect with a corrupted or malfunctioning stack.

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.

That is all I have to report concerning the corrupted stack. No idea  
whether any of the above is actually related to the cause of the  
corruption.  However, the process of dealing with this has raised a few  
other questions.

Regarding the immortal dialog stack that nobody could kill (Andre  
suggested that MetaCard could be lethal to it, however), and which  
Andre has immortalized in his screen shots:  What seemed to have  
happened (before the no-Windows crisis) was that I downloaded an  
alternative dialog stack because I hated the three-mile-wide default  
dialog thing.  Once it was brought in as a substack, it appeared in the  
application browser, and seemed to always pre-empt Revolution's own  
dialog stacks in the IDE. It was a strange neon color so I fiddled with  
it, but it always looked ugly and finally I zapped it. But, as Andre  
discovered, it did not die.  There was absolutely no way to get it out  
of the stack.  You could disappear it from the browser and save, but  
when you reopened the mainstack it would reappear again. I figured it  
kept appearing in the IDE because it had somehow preempted the  
Revolution dialog stacks, but in that case why did it keep reappearing  
in the application browser as if it belonged in my application even  
though it was now working for the IDE?

But here is something else kind of neat.  When I finally gave up trying  
to make the alternative dialog stack look presentable, I zapped it, and  
when it was reincarnated it had picked up the background image of the  
mainstack!  This was, in fact, highly desirable. I liked it. It carried  
over beautifully to the OSX builds (of course, I never saw it in the  
Windows builds). I might try to make it happen again. If this can be  
tamed, it would be a useful addition, maybe?

In the end, I rid myself of the immortal dialog stack by creating a new  
mainstack and pointing all the substacks to it.  That left the old  
mainstack and the immortal dialog stack in a little universe of their  
own, after which they were closed and consigned to the dustbin of  
history.

Finally, the question with which it all began:  What in creation is a  
"0,0" error?  I have tentatively decided to interpret this as:  "I  
don't have the slightest idea why I cannot open and run your perfectly  
good application."

====

Information from Richard Gaskin re: corruption, esp. image corruption:

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.



On Aug 15, 2004, at 8:31 PM, Stephen McNutt wrote:

> I'm having trouble with stand-alone builds of my application.  My app  
> runs just fine within the Revolution development environment.  I'm  
> using an iMac with the latest system software.
>
> Problem A:   When I build a Windows stand-alone, it runs just fine  
> within Virtual PC 6.1 on my iMac.  When I stick it on my flash drive  
> and take it to a PC, I get generic icons (not the custom one I built  
> with IconFactory--which shows up just fine within Virtual PC) and the  
> app won't open.  I get an error message that says something about  
> initialization failing and that the error was 8, 0.
>
> Problem B:  When I build a Mac OS X stand-alone, the program opens but  
> doesn't function.  I believe I've determined that it hasn't found the  
> data files it access upon startup to get saved variable values.  I  
> wrote the following code to get it to access the data files, and this  
> code was working until a couple weeks ago:
>
>     if the environment is not "development" then
>       if the platform is "MacOS" then --Sets the default folder to the  
> correct folder within a Mac OSX bundle (package).
>         put defaultFolder into ldefaultFolder
>         put "/CQ.app/Contents/MacOS/" after lDefaultFolder
>         set the defaultFolder to lDefaultFolder
>       end if
>     end if
>
> During development, the data files are inside a folder, which itself  
> is in the same folder as the application.
>
> Anybody got any insight into what appears to be two separate problems?
>
> Thanks,
> Steve McNutt
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>