Hi Dan.

The project I work on has a main FoxPro .EXE that calls several different FoxPro .EXEs, which in turn can call FoxPro .EXEs. I've had some various problems with the debugger, but most of them I've been able to overcome.

I haven't had much success setting breakpoints from the code window. I usually open the debugger, then open the .EXE from there which pops up a list of the programs. I then set the breakpoint(s) here, which seems to work fine. Sometimes setting the breakpoints in the code window works, but only after I compile the project. Usually, though, the breakpoint is either on the wrong line, or it appears to be on the right line, but the code doesn't break there.

I've also had FoxPro bomb on me while the debugger is open. Usually when I exit any of the sub-EXEs while the debugger window is up, I'll get a C5 error which shuts down FoxPro. I now have a shortcut key combination set to open the debugger (run the DEBUG statement) to bring up the debugger when I want, and I keep it closed the rest of the time.

Jonathan

>>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.