Buggy debugger -- solved?

[Timothy Miller]

>On 7/11/05 8:34 PM, Timothy Miller wrote:
>
>>The details of my debugger frustration, previously described:
>>
>>>It works fine on, for example, a simple mouseUp script in a simple 
>>>button. However, if the button sends a message to a handler in a 
>>>stack script (for instance), which then sends another message to 
>>>another handler, nested or not, the debugger won't follow along. 
>>>"Script debug mode" is definitely turned on. Step Into, etc., are 
>>>absent and/or dimmed out, typically. Sometimes, I can see the 
>>>script window open, several windows back, but I can't get to it 
>>>until the script is done executing. I've tried setting multiple 
>>>breakpoints in each handler, tried setting breakpoints by script. 
>>>The script rolls right past them.
>
>I think Eric mentioned this after you wrote last time, but the 
>debugger doesn't track "send to" messages. It tracks everything 
>else, but if you "send" a handler to another object the debugger 
>won't follow along.
>


Thanks to Eric, Jacque and Mark on this thread. And thanks to Dan, again.

First, let me clarify what happens, and what doesn't. The script 
window opens at the breakpoint, but it does not come to the front, 
and the script does not pause at the breakpoint. After the script is 
done executing, I can move the script window to the front, but it 
does me no good.

Oops! I just solved part of the puzzle, but mysteries remain. Feel 
free to skip to the second row of asterisks if you want. The details 
lie between the asterisks if anyone is interested.


************************** the dull details, perhaps now irrelevant, follow:


Here's a typical sequence of events.

On mouseup
     get this
     put that into field "theotherthing"
     etc.
      goForIt -- this is a message sent to the background script. The 
bg script does receive it, and the script executes fine, but I can't 
debug it.
end mouseup

Now, in the background script

On goForIt
      handler1 -- this massages some data, without changing stacks or 
backgrounds. It terminates, so the script moves onto the next handler 
in goForIt
      handler2 -- more of the same
      handler3 -- this goes to another stack, picks up some data and 
returns. It also terminates
      handler4 -- this is a handler that doesn't terminate. The next 
handler is nested, in other words. Depending on an operator, it calls 
either handler5 or handler6
end goForIt

The command "send" does not appear anywhere in this sequence.

In reaction to the good comments of the good people on this thread, 
and also in reaction to my desire not to look like a whiner or an 
idiot, I re-tested. Same results. As follows:

If I put the breakpoint in the button, the button script does open, 
and I can "step into" through the lines of the button. Once the 
script gets to the goForIt message, the script executes without 
pausing, even though the window of the bg script opens.

If I put the breakpoint at the beginning of the goForIt handler in 
the bg script, at the the handler1 message, at the beginning of the 
handler1 handler, in the middle of the handler1 handler, or all of 
the above, or do the same with any other handler in this sequence, 
the same thing happens. The script window opens, but it's not the 
front window, and the script runs to completion, without pausing. 
When the script has executed, the script window remains open.

After reading the docs again, I realized that I can initiate 
debugging when the error window opens. So, I deliberately placed an 
error at various points in the goForIt handler, or in hanlder1, 
handler2, etc. The debug button on the error window did respond, and 
took me to the error. The script has paused, the script window opens, 
but the debugger buttons at the bottom of the script window (step 
into, etc.) are absent, and the corresponding items in the debug 
window are dimmed out. The script stalls. All I can do is remove the 
offending line, save, and run the script again.



**************************  The more productive part starts below:



Maybe there's something about background scrips. As I write this, it 
strikes me that I've put most scripts of this nature in the 
background script. I just tried a similar kind of 
button-handler-handler-etc situation, where all the handlers are in 
the stack script. These seem to debug just fine.

Maybe this is why the debugger seems to have worked at some times, 
not at others. I didn't notice the pattern before.

Now I'm going back to the script described above. I'm moving handler1 
to the stack script. If I put the breakpoint at hanlder1 in the stack 
script, I can "step into" all the way thru handler1. When it 
terminates, and control reverts to the bg script, I can't debug any 
further.

My hypothesis is -- there is something different about bg scripts -- 
maybe several things. In a way I hope so. I'm gonna feel really 
stupid if no one can reproduce this issue at this point.

If background scripts are "different," what's different about them? I 
looked through the documentation pretty carefully, but didn't find 
any mention of this.

If others on the list haven't have this problem, maybe most 
experienced users avoid background scripts, avoid turning on "behave 
like a background" or don't have HCaddressing turned on. (In my case, 
"behave like a background" and HCaddressing areturned on.) If that's 
true, few people on the list would have noticed this issue. It's also 
possible it's an OS X-only problem.

Should I have known that the debugger doesn't work properly in bg 
scripts? Or maybe this is an un-reported bug in the debugger?

Your ever faithful fumbling amateur,


Tim