mark cards by finding -- new insights

[Alex Tweedly]

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