Timothy Miller wrote:
I am sympathetic, Eric. If it's me and not Rev, I want to know it. If
it's a Rev bug, I'm now a Rev loyalist, so I want Rev to know it, and
if they don't have the resources to isolate it, I'm willing to help,
up to a point.
It would help if I could get the damned debugger to work. Could you
toss me a clue? It sure doesn't act like the hyperCard debugger.
I've never used the hyperCard debugger (or in fact hyperCard) - so I'll
refrain from comparisons :-)
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.
The debugger has some issues - but for me at least it basically does
what I need it to do, more or less, most of the time. In 2.6, they (Rev)
added basic (inadequate) support for array, which was the biggest thing
completely missing - so I'm relatively happy with the debugger.
In my experience, it will stop at breakpoints, and will generally then
"step over" or "step into" adequately. Note that it will "step into" if
you call a function or a handler - but it will NOT do so if you "send
message".
So if I'm in my mouseUp handler, stopped at the first of the following lines
put 3 into i
myHandler i, "try this"
put 4 into i
then wither a "step over" or "step into" will move me to the next line.
Then another "step into" will move me to, and stop at, the first line of
myHandler.
Alternatively a "step over" would stop me at the next line (put 4 ....")
However, if the code was instead
put 3 into i
myHandler i, "try this"
put 4 into i
then the code would do pretty much the same thing (not quite, order
would be different) but the debugger behaviour would be very different
because it would never pause within myHandler.
The other thing to watch our for is that stepping *out* of a function or
handler also, I think, requires you to use the "step into" button.
It's (IMO) a very misleading label on the button - it really means step
to the next statement even in a different handler context - either
entering or leaving. (Hmmm - I can see why they didn't call it that :-)
Anyway - I use "step into" all the time, except when I deliberately wish
to step over a function or handler.
One more thing to watch for - closing the debugger/script window is
equivalent to clicking "Run" !!
Since you no longer have the debugger control window open, what can it
do but try to continue. Makes some sense - but caught me out often until
I got used to it. Makes me really, really wish that this window had a
"minimize" control - but I get used to just shuffling windows of to the
edges of the screen while I try to see what's happened.
The instructions say, "The breakpoint command has no effect unless the
stack is running in the Revolution development environment." I'm using
DreamCard. Does DreamCard count as the "revolution development
environment?"
Yes.
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.10/43 - Release Date: 06/07/2005
_______________________________________________
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
