Or alternatively, check the pendingmessages and only send if there is not already a message for the handler in question in queue.
I've had situations (in my case, bad coding) where I thought I was starting a looping handler once ,but had left a call to that handler elsewhere accidentally during the re-think process. In those cases, even if it is a seldom run handler that has the mistake, every time it is called, a new instance of the loop starts. In my case, (since I have trouble tracking details as complexity grows beyond a certain point.. Small scale I'm great, large scale, not so much) I've just made it a habit to always do the pendingmessage check before sending again. (I have lots of little rules like this to help me manage my own personal limitations in a consistent way.. Like always including a way to exit a tight repeat loop during development at least, to avoid issues with runaways.) Hmm. I tend to run on about things lately don't I? Feel free to ignore any extraneous blab. On Sun, Jul 8, 2018 at 10:42 AM Douglas Ruisaard via use-livecode < use-livecode@lists.runrev.com> wrote: > To help determine if Brian's suggestion is occurring, you could put the > following line in your "self perpetuating" code (assuming you're not > running the code on a Mobile device which have no "messsage box") just > before the "send... in x time ": > > put the pendingmessages > > If you see ANY output, then you've got multiple overlapping messages ... > again, this assumes you only have ONE "loop" running. Perhaps you can send > the "offending" section of code for analysis? > > > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
