Stopping program execution in the IDE

[Havanna]

maybe I just haven't found it …
Ever so often I manage to lock up the IDE, simplest example:

on resizeStack
answer the width of me
end resizeStack

Resizing lock up the IDE ocmpletely, I can't get out of it and have to kill the livecode task

A way out of this would be nice.

[sefrojones]

That's a bit odd, I just tried to hang the IDE with your resize script in ln Ubuntu 14.04 with LC 6.5.2,6.7(rc2) and 7.0(rc2), and it seems to work well, I could not cause the lock up that you mentioned. Although it seems to me that using "answer" might be your problem. If the LiveResizing of your stack is true, then (according to the dictionary) the message is sent continually during resize, which seems like it would try to open many answer dialogues simultaneously and lead to the lock up that you mentioned. You could try using CTRL-PERIOD , which is the "emergency brake" in LC......

--Sefro

[FourthWorld]

ResizeStack messages are particularly problematic, because the OS sends them in an ongoing fashion while the window is being resized, causing them to queue in tight loops. If within these tight loops you're trying to do something you don't really want to do (like constantly bringing up an answer dialog each time the stack gets that message), it will be annoying.

In cases where your resizeStack handler is being interrupted by an error, the debugger will let you type Cmd-Y to stop it, even when the even queue may be too tightly packed to allow you to select the Stop item in the Debug menu.

But here, unfortunately LiveCode is faithfully doing exactly what the script asks it to do. Even if you type Cmd-. to stop non-error script execution, the next resizeStack message will just trigger the handler again right after.

If you stop resizing the stack and keep dismissing the answer dialog, eventually the queued messages will cease. If that takes annoyingly long, you can always force-quit as you did.

Because many people use answer dialogs as a way of debugging (not a good practice with events like resizeStack, as you've discovered, or within long loops), the engine team has been exploring ways to cancel out of message queues while a dialog is present. This is tricky stuff, though, and not likely to be implemented in either v6.7 or 7.0, as it would deeply impact many aspects of how events are handled in nested internal event loops when modal dialogs are present, and their options would have to be considered very carefully.

So in the meantime just use "put" rather than "answer", and you'll have a non-blocking way of getting feedback while testing your UI. If you need more granular control while debugging, consider using the Debugger.

[Havanna]

Well, thanks anyway - that's about what I thought.
As the current project has to go desktop as well as mobile, I'm using answer because that gives me a quick info on both - just have to be more careful.

[malte]

what I usually do is:

Code: Select all

on resizeStack
  if "resizeStack" is in the pendingMessages then exit resizeStack
  doUpdate
end resizeStack

on doUpdate
  -- whatever
end doUpdate

That way it is less likely to get stuck...

[FourthWorld]

I believe the pendingMessages only contains messages queued with the send command using the "in <time>" option. If you're able to catch system messages there I'd be interested to learn how you do it.

[malte]

Seems you are right Richard...

Code: Select all

on resizeStack
   send "doUpdate" to me in 1 millisecs
end resizeStack

on doUpdate
   if "doUpdate" is in the pendingMessages then exit doUpdate
   answer "boo"
   anyErrorHere
end doUpdate

Works though...