Hoi peter,

>We've noticed that this has consequences for the availability of debug-information (presumed that debug-info is included anyway). Debug-info seems fine for forms and classes. However, when debugging a PRG, the Trace-window has a message 'Source not available', even if the PRG is available along the searchpath.

>In case a Microsoft representative reads this message: We regard this behavior to be a real vfp-quirck, because we can't imagine that it's 'a feature by design'. What's your vision??

>Here's the question for All: Does anybody know of a workaround??


As you know I'm not a Microsoft representative, but I'll try to explain the cause of the behaviour:

All objects in the project use relative paths if possible. These relative paths are stored in forms-, class- (the classlib field) and in the project.pjx tables (and maybe other internal tables). This makes it possible for the debugger to find the source object.
When building the module, the home dir of the module is the same dir as the project files. It does not matter if you build it to another dir than the project dir: the internal references stay the same. However, you're not executing the module in the same directory of the project and it thus cannot find the contained objects. I suspect this behaviour is by design.

One workarround that should work is to move the project files to the same dir where the app is executed and tested, and build your application from there.

In the past i've tried to hack those files and remove all relative pathing (with JUSTFNAME(), this way VFP does search trough the path setting), however, this causes problems when developping because the project manager might not find all objects again.

I've played with the thoughts of building a project class which would make a copy of the project, remove all overhead from the sourcefiles and build from the copy. However, I never started this project and don't know if this even would be possible.

Walter,