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