>Before you compile, go to the VFP menu and click on Project, then on Project Info. Make sure Debug Info is checked on the Project tab. Then as long as the debugger is open, breakpoints will be honored when hit.
>
She no workee. I have the debugger open and can see the breakpoint listed, but the EXE blew past it like a freight train.

This nightmare of a project is built having a primary EXE which calls a secondary EXE. Both have the Debug Info checked in the Project Info. No loose coupling here, everything is totally dependant on the system being started from the primary EXE. I didn't build it that way, I just inherited it.

Maybe I'm too old a dawg but I tend to dismiss anything that doesn't work the first time out. There's a lot of power with breakpoints but if they don't break where I need them, SET STEP ON is the way to go. And if THAT causes a C...5 error, well...the term "hosed" comes to mind.

My other complaint is that breakpoints aren't visible in the source code (only when viewing thru the debugger). Maybe they should be called minepoints (as in "landmine").

Don't get me wrong - I'd prefer to use them. In a previous project, one of my Golden Rules was that all forms were to stand alone of the project, and in that kind of scenario breakpoints would probably be perfect (although in a room of sixteen developers, I don't think anyone knew how to use them). It's just that they aren't a dependable way of breaking code.