Did you try forcing the animated GIFs to play by setting their repeatCounts to -1? Maybe something like:
[button script] on mouseMove set the repeatCount of img mySrcImg to -1 end mouseMove
Yes, indeed. I was even able to prove that the repeatcounts were set by executing
put the repeatCount of image "myGIF" of cd "myDisplay" of stack "myMainStack"
it always showed up as (-1), even tho seen through the button it had stopped moving.
> I have worked hard to try to isolate this problem, including generating a > whole external logging scheme to keep track of the program execution, but I > don't seem to be getting anywhere - it looks as if the app crashes near the > beginning while opening some substacks (usually invisible).
Are you sure the app has crashed? Are you saying the app is completely non-responsive or stops functioning at a certain point? It is unlikely that anything like this is caused by animated GIFs (a corrupted image can result in a jumbled mess of rainbow looking static but this usually does not inhibit the operation of scripts).
Well, I have a logging system (I mark specific points which the program executes in setting itself up etc by calling a routine that writes short lines of text to a log file). In the working versions of the app, this log has a complete trace of the whole startup process; in the 'crashed' ones, however long I wait, only the first few messages are logged - and the only thing to appear on the screen is an Anchor stack that is normally hidden, plus a splash screen stack with a corrupt display (the card contains a snapshot of part of the PC display). This is one scenario - in my tinkering to try to improve matters (for example when I moved the GIFs back to the display) then I get a real crash ('this program has performed an illegal instruction' type of message from Windows). The log file in this case is also incomplete.
If you can generate the problem in a stack that contains only your buttons, images and drag scripts, then you should be able to track down the problem there. Otherwise, something else is going on in your stacks/scripts.
Yes, Ken Ray also suggested this and it's certainly the way I would expect to present a bug to the RunRev team if I could. Unfortunately I have been trying to do exactly that for some time, but it ain't simple! So far I have not got a 'boiled down' version to show the error. This probably means that I will have to start with all the code that I know gets executed before the crash and keep simplifying it until the problem goes away - a fairly long job. I am quite prepared to agree that the problem is in my scripting, **except** that if it works in one version of Windows, according to RunRev, it should work in them all.
Ken Ray wrote:
The other thing that might help (since you say you added a logging system) is to see what was the very last thing to happen before the crash. If it crashed when opening a substack, try to identify which substack. Remember that images load into memory when a stack is opened, so if you open a substack that has a lot of images on them, they will all load into memory.
For earlier versions of Windows, I've encountered that most crashes are related to memory. How much memory does the 95/98/ME machines have that you've been testing on?
I'm looking into this (I'm not physically near these test machines at the moment) - I think the 95 and 98 systems I've encountered probably have very little memory (they're such old machines) but I believe that the ME machine has a massive amount - that's the one that belongs to my beta tester, and she's doing a lot of software development work on it (in VB mostly) which calls for lots of RAM, I believe. However, I will check all this tomorrow.
Thanks again
Graham
---------------------------------------------------
Graham Samuel / The Living Fossil Co. / UK & France
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
