The bad guy in me say use git with that versioning problem and there is no problem. If you have removed the breakpoints, the files are the same.

You can do some expression that enables breakpoint again. Like IIF(PROGRAM(-1)=xxx,LINENO()=nnn,.F.) in watch window, breakpoint it, should stop on line nnn stacklevel xxx
Just place it as default in your watch window and alter the numbers as you need it. Or use publics, or ...

HTH
>Thanks Lutz,
>
>Yes, I've taken to figuring out using PROGRAM() etc but that can be a pain as well (each some other method or prg is called). And I have reluctantly put in SET STEP ON at certain points - reluctant as it is someone else's source code (and thus I change the date/time on the file which always then throws me if I have to check their versions - so I end up making copies of the class and putting them back when done so that the original datetime are on the files).
>
>Albert
>
>>>Hi,
>>>
>>>I am having trouble with the debugger and wondered if I have triggered some sort of setting some place or maybe the framework being used is doing something odd.
>>>
>>>If I set some breakpoints, they often do not get "respected" i.e. set a breakpoint for when a certain method fires and then I often want to either "run to cursor" or I mark a line way down in the code to stop again and then I resume so I don't have to step through everything.
>>>
>>>Somehow the breakpoints are not being respected and the entire method runs and finishes. If I look at the breakpoint dialog, they are still set but somehow the deugger is not stopping.
>>>
>>>Is there a setting some place or is the framework somehow clearing things?
>>>
>>>Thanks.
>>>Albert
>>
>>No. This is like it is. Occurs normaly in deeper class levels. Sometimes one can fiddle around with expressions
>>composite of PROGRAM and the like, or watch for specific variables. Normaly the sole solution is a assert or set step on on the place you need it.