>Dragan,
>
>I found a workaround.
>
>First, my StartCB.prg was setting up my path using paths to several application folders relative to the current folder (e.g. "Data, Libs, Progs, Include, ...") and framework paths using the full path including the drive. I changed StartCB to add sys(5)+ curdir() to the folders relative to the application root folder.

Here's what I usually do for setting paths:

proc addpath
lparam cpath
cpath=fullp(addbs(cpath))
if dire(cpath)
	if atc(cpath+',', set('path')+',')=0
		cpath=set('path')+','+cpath
		set path to (cpath)
	endif
endif

Note line three... that's the key. I always have the relative paths converted into absolute paths somewhere in my start.prg, at least the one I use to run tests. I just Do AddPath with "libs", Do AddPath with "prgs"... and that's probably why it works for me.

> Then I changed all the #INCLUDE "INCLUDE\APPINCL.H to #include "AppIncl.h" This got around the problem.

I still don't have to do that... go figure.

>I tried just changing the path without changing the #INCLUDE, but that was not sufficient. The compile to FXP still couldn't find the INCLUDE\APPINCL.H file, which is what I expected based on previous experience.
>
>By the way, even though the compile does not report any errors when it fails to find the include file, it drops a .ERR file in the same folder as the PRG and FXP with a message about not finding the include file.
>
>Based on all this, it appears to me that the compile to FXP is done as if the curdir() was the folder where the PRG is located, whereas the compile to PJX is done using the curdir() as it really is. I'm not aware of any VFP settings or options that would affect this other than SET PATH.
>
>It still looks like a VFP bug to me. But I think I can live with the workaround.

Same here... each new version of VFP there's a 20-minute (at least) hassle to get this straight. With versions coming up once in a couple of years, not too bad, eh?