Windows Misery

[Graham Samuel]

Thanks for the replies on this (Alex Rice, Ken Ray and Scott Rossi). Scott 
asked:

>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