>I found out about about the second copy of the compiled code a while ago, but I always assumed (incorrectly) that when I recompiled all files it recompiled both copies. I also naively thought it recompiled both copies when I edited the PRG, but it only recompiles the FXP. The weird part is that having separate copies in the PJX and FXP didn't cause many problems in VFP 6 but has this major glitch with includes with VFP7 - VFP9. (Granted there were times when I inexplicably got odd messages about the source code not matching, but deleting the FRX to force a recompile always fixed that.)

Seems to be that report is really listening to you :).

>>Now what's up with your include files, I have no clue. I've seen my share of weird behaviors there, and one thing I know that helps is to have the include directory in the Set("Path").
>
>The folder is in VFP's Set("Path") and it still doesn't work with or without the path part of the Include filename. I suspect the way PRGs get compiled when building and when saving changes is somehow different and the path and current folder are being used for the latter, but not the former.

Just checked mine... and I'm having the .pjx in the current directory, and all the prgs have the
#include include\appl.h
line in them. The prgs are in a .\prgs subdirectory, so the path in the #include is not relative to the location of the prg itself, but to VFP's current directory when it runs them, or when it builds.
Most of the time I'm building an .app file (which is a regular build but doesn't increase the build number, which I find cool), but then sometimes I do run the prgs directly while trying things out, and don't have any trouble with include files... not now. I did have some when I moved stuff around, or when I switched from VFP7 to 8 and some of the classes (not prgs) were pointing to an include file of VFP7, not 8... which, again, worked fine as long as it was all on the same disk, but when I moved the whole project to a different disk, all the relative paths to home() were screwed.