Beachball of death

[Jon]

Tim:

I would GUESS that one way to make this happen (to bowl the beachball of 
death) is to have two handlers trigger each other in turn.

Suppose you have an object for which you have specified Geometry.  This 
means that Rev will try to modify the size and/or location of the object 
for you as the stack is resized.  If you then write your own On ReSize 
handler, and accidentally modify the size/location of the object, I 
wonder if Rev would "know" what you did, and try to "fix" it.

Now that I read what I've written, I doubt that this specific situation 
could cause a repeated/recursive handler call, but perhaps something 
like it. 

One approach to debugging it would be to put breakpoints at the start of 
every non-trivial handler, and see what happens.  When I say 
non-trivial, I'm not so much talking about the complexity of the handler 
as I am about the function, whether it might interfere with another 
handler that is also present.

I hope this theoretical discussion does not turn out to be a waste of 
your time.

:)

Jon


Timothy Miller wrote:

> Many thanks to all on this thread.
>
> After suppressing messages, I opened the stacks in question and combed 
> through their stack and bg scripts, commenting out all non-essential 
> handlers. I would have done this sooner, except the symptoms seemed to 
> suggest a corrupted stack or corrupted application.
>
> After saving, restarting Rev, and non-suppressing messages, these 
> stacks seemed fine. The essential features still work. I guess I'll 
> just comment the handlers back in, very carefully, one at a time, 
> while carefully reviewing each one for possible small errors. The 
> problems will make themselves known as I go along, most likely.
>
> These are HC --> Rev stacks. I suspect a few handlers left over from 
> HC contained some minor errors, which HC ignored. They didn't 
> necessarily cause error messages in Rev, either, so I didn't know they 
> were there. These, in combination with a few new errors, also minor, 
> apparently made Rev go insane. In HC, the same errors would have 
> generated easy-to-understand error messages, at worst.
>
> I guess the rules of the game have changed. I'm certainly going to be 
> more cautious than I used to be when writing new handlers.
>
> Maybe I'm wrong, though I never once made HC go insane with 
> conventional handlers doing conventional things. The occasional 
> infinite repeat loop was easily interrupted with command-period. If 
> I'm wrong, please correct me.
>
> If someone can explain how conventional handlers doing conventional 
> things can make Rev go insane, and what precautions to employ in the 
> future -- other than the obvious ones, please speak up. Being a 
> perpetual scripting novice, I wrote my crude HC scripts by trial and 
> error. They either worked or didn't or generated simple error 
> messages. I'm going to have to change my ways, I suppose.
>
> Cheers,
>
>
> Tim
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>