step in debugger?

[Charles Hartman]

Thanks. No, that twist on it I had recognized -- so if I need a  
breakpoint-and-step at the end of a handler, I put in a "put 0 into  
tDummy" line at the end.

In this case, the breakpoint line is in the middle of the handler, in  
the middle of a repeat loop or a 'try' structure. (Now I can't  
remember which handler I was debugging yesterday when I finally  
noticed this! though I know it's happened before.)

Is it possible that "try" doesn't mix right with breakpoints and  
"step"? But I know I noticed step misbehaving when there *wasn't* a  
problem in the code, so it's not a matter of the "try" having kicked  
me out into the "catch". (And in that case, shouldn't "step" take me  
to the first line of the "catch" anyway?)

I hope this makes more sense. I *think* this was the code I was  
debugging:

     repeat for each line tLine in fld "playerListFld"
         if tLine is not empty then
             put empty into tPlayerRecToStore
             put word 1 of tLine into tPersonID
             put tPersonID into tPlayerRecToStore["personID"]
             put tPerformanceID into tPlayerRecToStore["performID"]
             -- apparently no good way to "batch" store all these  
records
             try
                 get libdb_addToTable(gDB, "players",  
tPlayerRecToStore, "personID")
             catch errMsg
                 put false into storeOK
                 handleDatabaseError errMsg
             end try
         end if
     end repeat
     select text of fld "playerListFld"
     [and so on . . .]

with the breakpoint on the "get libdb_ . . ." line.

Charles Hartman

On Oct 26, 2005, at 10:16 AM, Alex Tweedly wrote:

> Charles Hartman wrote:
>
>
>> I've been bumbling numbly along with debugging -- and somehow it  
>> just  occurred to me that something's wrong here:
>>
>> I put a breakpoint on a line in the middle of a script, run till  
>> I  hit it, look at some variables, press Step . . . and the script  
>> runs,  not stopping till complete/crash/next breakpoint.
>>
>> In any other debugging environment I've seen, that's not what  
>> "step"  means. It means execute the currently-highlighted line and  
>> stop.
>>
>>
> "step" means (pretty much) what you'd expect it to mean from other  
> environments - so there is something specific going wrong.
>
> One possible (maybe even likely) candidate is that if you are  
> putting your breakpoint on the last statement in a handler or  
> function, then Step will just run onwards - you need to use "Step  
> into" to step in *or out* of a handler or function. (There is a BZ  
> for this, I believe).
>
> If it's not that - please tell us more....
>
> -- 
> Alex Tweedly       http://www.tweedly.net
>
>
>
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.361 / Virus Database: 267.12.5/149 - Release Date:  
> 25/10/2005
>
> _______________________________________________
> 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
>