graham.samuel at wanadoo.fr
Thu Nov 13 16:50:43 CST 2003
Thanks for the replies on this (Alex Rice, Ken Ray and Scott Rossi). Scott
>Did you try forcing the animated GIFs to play by setting their repeatCounts
>to -1? Maybe something like:
> 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
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
> > 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
>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.
Graham Samuel / The Living Fossil Co. / UK & France
More information about the use-livecode