Buggy debugger -- solved?

[Timothy Miller]

It looks like this thread might die. I hope not. I hope a 
knowledgeable someone is going to reply. I'd sure appreciate it. I'm 
depending on you guys. I've searched the docs, learned nothing, and 
taken all advice offered so far. Where else can I turn?

The gist is, the debugger works fine in stack scripts, but I am not 
able to debug any background script. I'm talking about bg scripts 
that work perfectly, every time.

If I move any background script to the stack script, the debugger 
works perfectly. I can replicate the problem, every time. If I split 
a sequence of handlers between a background script and a stack 
script, I can debug those in the stack, but not those in the 
background.

Is this a bug or a feature? Is it well known? Documented? If so, 
where? If it's a bug, has it been reported? Has it been fixed?


Cheers,


Tim


>>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
>_______________________________________________
>use-revolution mailing list
>use-revolution at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your 
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-revolution