Hi Mark,
I found a workaround. I can debug a bg script with no problem as long
as I do it from card 1 of that bg. Otherwise, the debugger window
opens, but it does not debug. Several subscribers have replicated the
problem, and the workaround. It's not a big deal if you know the
workaround. If not, it can be very frustrating.
I have version 2.6.1. It's not fixed yet. I believe it has been BZ'd.
I'll take a look at bug 329.
Best regards,
Tim
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
_______________________________________________
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
