When does recursion limit bite you?

Alex Tweedly alex at tweedly.net
Tue Oct 4 05:10:24 EDT 2011


I expect that the error message happens when the number of handlers in 
the call stack becomes too high; that would almost always be due to 
recursion.

Does your handler do "wait with messages" or "send" or any other 
'message path invoking' action ? If the engine has an opportunity to do 
a message dispatch while your handler is running (i.e. before you return 
from it), then that would allow the mouseMove to be run, invoking you 
handler again while still "within" the earlier calls.

If your handler can take some time to run, you might want to consider 
whether it can be modified so that at some point you 'send' to one of 
the handlers rather than call it directly. That would then allow the 
engine to dispatch that 'sent' message *in turn* - i.e. if there was 
already another mouseMove waiting dispatch, it would come before your 
handler. This might allow you to skip processing 'redundant' actions 
which have been already superseded by the later mouseMove.

But it would require some care to make sure that you keep properly 
synch'ed, and that you don't simply pile up a list of sent messages to 
handle later.

-- Alex.

On 04/10/2011 08:34, Malte Brill wrote:
> Hi all,
>
> I am a little stumped atm. From time to time I see a "recursion limit reached" error popping up, even though there is (and this is debateable) no recursion happening in my scripts. At least not obviously. But it seems that one has not understood recursion as long as one has not understood recursion. The handler in question is called from mouseMove. So I guess there is a lot of calls piling up there when the mouse is moved quickly. However, recursion might be a bit misleading here, as the handler does not call itself. Or does the error message also apply for the message queue? Can someone enlighten me? I am currently thinking of flushEvents("mouseMove") at the end of the handler that gets called from mouseMove? Do you think that will work?
>
> All the best,
>
> Malte
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>





More information about the use-livecode mailing list