Tim,
I would like to know whether you have solved the problem you had
with debugging background scripts. If not, feel free to send you
stack to me. You can also add your (very good) analysis to bug
329 of the Bugzilla database.
In my view, the debugger should never just drop out of debug
mode. It should give some feedback to tell the user why it can't
continue debugging. If we can figure out what happened with your
stack, maybe RunRev can add some proper error handling in the
deugger.
Best,
Mark
P.S. I'm quoting the entire previous message to make it easier
to recall the discussion.
Timothy Miller wrote:
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
--
eHUG coordinator
mailto:[EMAIL PROTECTED]
http://www.ehug.info
http://home.wanadoo.nl/mark.sch
http://www.economy-x-talk.com
Please inform me about vacancies in the field of
general economics at your institute. I am also looking
for new freelance programming projects.
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
