tracking down freeze based on timing, maybe?

[J. Landman Gay]

On 12/13/2015 10:00 PM, Matt Maier wrote:
> It starts with a mouseMove handler, which is where it returns after stuff
> has happened.
>
> One of several options is followed by a freeze. I setup a little handler to
> log the seconds every x milliseconds after that. Nothing is happening a
> split second after the script returns to the mouseMove handler. It's like
> whatever's hanging up the application is outside of all the stuff I wrote,
> so I'm not sure how to dig into it.

Mousemove is sent a whole lot and messages may be piling up in the queue 
while LC tries to catch up. Try removing the mouseMove trigger and start 
your handlers some other way. If that fixes the problem, then that's 
where to focus.

Typically we add a "busy flag" to handlers so they don't try to do 
anything until the flag is cleared and it's okay to proceed.

local sBusy

on mouseMove
  if sBusy = true then exit mouseMove -- we're busy; don't do anything
  bigHandler -- if we get this far, it's okay to do work
end mouseMove

on bigHandler
  -- do stuff
  put false into sBusy -- clear the flag
end bigHandler

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com